read through the following page and keep it in mind when working in the editor we need to eliminate as much slowdown as possible in the editor to keep it running smoothly.
http://wiki.python.org/moin/PythonSpeed/PerformanceTips (http://wiki.python.org/moin/PythonSpeed/PerformanceTips)
Very informative.
I have a few areas of where I know I can make some improvements with the map() function. I also have been careless in regards to strings being immutable and have been using concatenation, so I have quite a few areas to improve there. I will go back through my code and make the needed improvements, thanks for posting that. :)
Nice find.
That one for concatenating strings is good and works for every language, not just Python.
In Data Aggregation I noticed something that wasn't mentioned in the text. I increased the performance in Atres dramatically a few weeks back by removing the temporary variables in most functions and using member variables instead. Basically the allocation of temporary variables is quite expensive. I've had a speed-up over 100% (from 30 FPS to 47 FPS).
Lol, xrange instead of range is mentioned there.
Though, I do not agree with one thing on the map/dict initialization. Exceptions are VERY slow and should be avoided whenever possible, especially in cases where they are used a lot like in a loop with many iterations. We had an huge overhead because of this in AprilUI at one point. After I removed the exception handling and instead changed to a different method (it was reading an XML document and checking the availability of an attribute through an exception) and implemented an alternative, suddenly reading the XML definition of our dataset became so fast that you wouldn't notice it anymore. Before that there was a significant an actually time required to read it.
hmm, that may be a good point about the exceptions. though the fact that python internally uses that method (caching exceptions instead of testing for the key's existence) seems to indicate that it holds some water at least as far as python is consurned. if the overhead for a map look-up is greater than propagating a clevel exception it would make sense.
Of course, I understand that. But he also listed other alternatives to exceptions for the key checking problem so you should use those instead of exceptions.