Coding for increased speed

Started by Ryex, October 29, 2011, 04:14:30 pm

Previous topic - Next topic

Ryex

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
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

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. :)
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

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.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

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.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

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.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.