Issue1665263
Created on 2007-02-21.14:37:19 by hsk0, last changed 2007-03-01.04:01:26 by hsk0.
Messages | |||
---|---|---|---|
msg2653 (view) | Author: howard kapustein (hsk0) | Date: 2007-02-21.14:37:19 | |
classDictInit() creates identical objects multiple times; this patch precalculates these redundancies: types.java contains patch 1665260 (the patch for [1661679] Invalid types.UnicodeType) typeshkopt.java is the optimized form --- types.java 2007-02-21 09:29:24.581942400 -0500 +++ typeshkpot.java 2007-02-21 09:32:43.356472100 -0500 @@ -13,48 +13,53 @@ // xxx change some of these public static void classDictInit(PyObject dict) { + // Precalculate some reused types + PyObject PyType_PyDictionary = PyType.fromClass(PyDictionary.class); + PyObject PyType_PyFunction = PyType.fromClass(PyFunction.class); + PyObject PyType_PyMethod = PyType.fromClass(PyMethod.class); + PyObject PyType_PyString = PyType.fromClass(PyString.class); + PyObject PyType_PyUnicode = PyType.fromClass(PyUnicode.class); + + // Let's do it... dict.__setitem__("ArrayType", PyType.fromClass(PyArray.class)); dict.__setitem__("BuiltinFunctionType", PyType.fromClass(PyReflectedFunction.class)); dict.__setitem__("BuiltinMethodType", - PyType.fromClass(PyMethod.class)); + PyType_PyMethod); dict.__setitem__("ClassType", PyType.fromClass(PyClass.class)); dict.__setitem__("CodeType", PyType.fromClass(PyCode.class)); dict.__setitem__("ComplexType", PyType.fromClass(PyComplex.class)); - dict.__setitem__("DictType", PyType.fromClass(PyDictionary.class)); - dict.__setitem__("DictionaryType", - PyType.fromClass(PyDictionary.class)); + dict.__setitem__("DictType", PyType_PyDictionary); + dict.__setitem__("DictionaryType", PyType_PyDictionary); dict.__setitem__("EllipsisType", PyType.fromClass(PyEllipsis.class)); dict.__setitem__("FileType", PyType.fromClass(PyFile.class)); dict.__setitem__("FloatType", PyType.fromClass(PyFloat.class)); dict.__setitem__("FrameType", PyType.fromClass(PyFrame.class)); - dict.__setitem__("FunctionType", - PyType.fromClass(PyFunction.class)); + dict.__setitem__("FunctionType", PyType_PyFunction); dict.__setitem__("GeneratorType", PyType.fromClass(PyGenerator.class)); dict.__setitem__("InstanceType", PyType.fromClass(PyInstance.class)); dict.__setitem__("IntType", PyType.fromClass(PyInteger.class)); - dict.__setitem__("LambdaType", PyType.fromClass(PyFunction.class)); + dict.__setitem__("LambdaType", PyType_PyFunction); dict.__setitem__("ListType", PyType.fromClass(PyList.class)); dict.__setitem__("LongType", PyType.fromClass(PyLong.class)); - dict.__setitem__("MethodType", PyType.fromClass(PyMethod.class)); + dict.__setitem__("MethodType", PyType_PyMethod); dict.__setitem__("ModuleType", PyType.fromClass(PyModule.class)); dict.__setitem__("NoneType", PyType.fromClass(PyNone.class)); dict.__setitem__("SliceType", PyType.fromClass(PySlice.class)); - dict.__setitem__("StringType", PyType.fromClass(PyString.class)); + dict.__setitem__("StringType", PyType_PyString); dict.__setitem__("TracebackType", PyType.fromClass(PyTraceback.class)); dict.__setitem__("TupleType", PyType.fromClass(PyTuple.class)); dict.__setitem__("TypeType", PyType.fromClass(PyJavaClass.class)); - dict.__setitem__("UnboundMethodType", - PyType.fromClass(PyMethod.class)); - dict.__setitem__("UnicodeType", PyType.fromClass(PyUnicode.class)); + dict.__setitem__("UnboundMethodType", PyType_PyMethod); + dict.__setitem__("UnicodeType", PyType_PyUnicode); dict.__setitem__("XRangeType", PyType.fromClass(PyXRange.class)); dict.__setitem__("StringTypes", new PyTuple(new PyObject[] { - PyType.fromClass(PyString.class), PyType.fromClass(PyUnicode.class) + PyType_PyString, PyType_PyUnicode })); } } |
|||
msg2654 (view) | Author: Charlie Groves (cgroves) | Date: 2007-02-28.18:47:38 | |
Did you actually see some slowness that caused you to do this? |
|||
msg2655 (view) | Author: howard kapustein (hsk0) | Date: 2007-03-01.04:01:26 | |
No, and I wouldn't have gone hunting for this at this time, but I as looking into 1661679 (Invalid types.UnicodeType), saw it used PyString instead of PyUnicode by mistake and noticed several redundant allocations, so while submitting the 1661679 patch I also tweaked the code. I saw the roadmap about v.Next focusing on cleanup and such, but this was low hanging fruit, already in the neighborhood and a straightforward patch so I went for it. What, that's a bad thing? |
History | |||
---|---|---|---|
Date | User | Action | Args |
2007-02-21 14:37:19 | hsk0 | create |
Supported by Python Software Foundation,
Powered by Roundup