|
intoK Apprentice
Joined: 18 Feb 2007 Posts: 190
|
Posted: Fri Nov 28, 2008 11:03 pm
[3.02] speed -- general |
2.37 %pathfrom(a,b) generating some 70+ rooms path - 150ms
3.02 500ms
2.37 #MAP over above rooms - 400ms
3.02 1500-2500ms
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Sat Nov 29, 2008 5:48 pm |
Remember that I have said before that I do not do any performance optimization until the mapper is actually working first. I have profiling utilities that I run later in the beta cycle to improve performance.
If these timings can be reproduced in the map file that you already sent me, please tell me the exact room numbers to try for %pathfrom to reproduce your results. |
|
|
|
intoK Apprentice
Joined: 18 Feb 2007 Posts: 190
|
Posted: Sat Nov 29, 2008 7:35 pm |
cool, but i also remember you wrote to post all mapper performance tests, even most subjective ones
1->10483, 23238 is another beast walk |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu Dec 11, 2008 10:25 pm |
Thanks for the map and the examples. I was able to find the speed problem in the speedwalk routines. It was actually the routine that built the speedwalk string based upon the search result. It steps through the search result and builds a linked-list of exit objects. To do this it was querying the database for each exit along the step rather than using the internal cache of exits.
In 2.37 this didn't matter because the entire database was cached within ADO/MDAC. But in SQLite, it uses a parameterized query to prevent a second copy of the database from being cached, and this is slower to do a query than just using the existing cache.
It really should have been using the cache all along...just got missed in 2.37 because ADO was covering up the issue with it's own cache. Anyway, it's nice and fast again for the next version. |
|
|
|
intoK Apprentice
Joined: 18 Feb 2007 Posts: 190
|
Posted: Sun Dec 21, 2008 6:10 pm |
i finally got to 3.03, path generation is pretty sweet now (~140ms), but #map still needs some work (~1500ms)
cheers! |
|
|
|
|
|