 |
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
 Posted: Sun Dec 09, 2007 2:18 pm
[2.16] Change in threading kills local variables
|
The actual test demonstrating this is in bold if anyone wants to skip the whole back story.
I have been working on the section of my mapper scripts that figures up the border rooms for a zone. This script has a lot of looping, and makes heavy usage of the %roomexits, %roomlink, %roomzone, and %reversedir functions. Currently I have the script designed so that it loops just as much with the things that were broken in 2.14a.
Some time comparisons for this script:
CMud Version (local variables all over the place)
2.14a: 7 seconds from command line
2.14a: crash using #THREAD (I only tried it once and that was after the command line test in the same launch)
2.15 and 2.16: 9 seconds from command line
2.15 and 2.16: 13 seconds using #THREAD
original zMud script
2.14a untested to many bugs in string handling to even test it.
2.15 and 2.16: 7 seconds from command line
2.15 and 2.16: 13 seconds using #THREAD
zMud 7.21: 7 seconds
I am finding some bugs still in the list handling that are likely the cause of the original zMud script not being any faster in CMud. The change in threading is obviously making a difference with all the various mapper functions the script uses and that is good. There is a definite speed problem though, and it seems to be in the handling of local variables. You can guess where this goes, another really big loop to work as a magnifying glass on the problem.
$var=%secs;#LOOP 50000 {$a=1};#SHOW (%secs-$var)
2.14a: 300ms
2.15 and 2.16: 6800ms
Slightly seperate item is that having the Package Editor open behind the main window makes this even slower with 2.15 and 2.16.
#THREAD a {$var=%secs;#LOOP 50000 {$a=1};#SHOW (%secs-$var)}
2.14a: 300ms
2.15 and 2.16: 300ms |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sun Dec 09, 2007 7:33 pm
|
I just did another few tests with this (v2.16 only) that actually show the problem is not confined to local variables. In fact just about everything seems to be running faster in the background thread. Hopefully I selected tests between the 2 posts that properly isolate the change in threading behavior from other bugs, or at least close enough that the pattern makes sense.
1. Launch, dismiss, command line
| Code: |
| #VAR a {} {};#NOSAVE a |
$var=%secs;#LOOP 50000 {a=1};#SHOW (%secs-$var)
6800ms with the odd spike as high as 10000ms. Spikes look to be a background db update even though that shouldn't occur.
#THREAD a {$var=%secs;#LOOP 50000 {a=1};#SHOW (%secs-$var)}
300ms consistently.
$var=%secs;#LOOP 50000 {#CALL %roomexit};#SHOW (%secs-$var)
12500 to 20500ms. I didn't open the mapper to test that.
#THREAD a {$var=%secs;#LOOP 50000 {#CALL %roomexit};#SHOW (%secs-$var)}
7000-7500ms. Again no mapper window open, but it looks this like it is doing the Synchronize.
Opening the mapper with (CTRL-M) changes the entire spectrum, and shows that the first test with %roomexit wasn't doing the Synchronize in the thread test.
$var=%secs;#LOOP 1000 {#CALL %roomexit};#SHOW (%secs-$var)
1500 consistently.
#THREAD a {$var=%secs;#LOOP 1000 {#CALL %roomexit};#SHOW (%secs-$var)}
2300-3300. So far this is the only one where the numbers seem to at least be in right pattern. This particular test is actually extremely close to the number of times a %roomxxx function is being used with the script I mentioned in my first post. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Tech
GURU
Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA
|
Posted: Mon Dec 10, 2007 1:46 am
|
Confirmed. Somethings definitely wonky in the main thread. I can't really tell in actual play, but for IRE folks for whom speed is everything, that's life or death.
|
|
_________________
Asati di tempari! |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 11, 2007 6:30 pm
|
I also confirm the speed difference. I'll see if I can figure out what is causing it. Also, I will be adding an option to the preferences that will allow you to select whether you want the command line to run in a thread or not. People who want to use Shift-ESC might prefer this mode. Also, putting the command line in a thread will allow the ESC key to be used to abort the script. So this will probably be set as the default for the public version.
But I'll keep the thread optimization for triggers and other scripts to minimize the number of Synchronize calls (assuming I can track down the speed problem). This should give the best of both worlds: faster triggers that don't always need to call Synchronize, but still being able to use ESC on the command line. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 11, 2007 6:32 pm
|
| Quote: |
| Spikes look to be a background db update even though that shouldn't occur. |
The background save will still happen once to initially create the "a" variable. Using #NOSAVE doesn't prevent the variable from being added to the database package, it just prevents changes to it's value from being written to the database. So it might be a good idea to add a call to #SAVE right after creating the variable to make sure the database is up-to-date before you start changing the value of 'a'. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 11, 2007 7:03 pm
|
OK, I found the speed issue. When threads were not being used, CMUD was trying to check the Windows Message queue for the ESC key. This was happening *each* iteration through the loop. Since the option to use a thread for the command line uses the better method for checking for the ESC key (and also Shift-ESC), I just removed this testing of the Windows Message queue entirely. Now the command line is slightly faster when not using a thread as you'd expect:
$var=%secs;#LOOP 50000 {$a=1};#SHOW (%secs-$var)
v2.17 Using command line thread: 830
v2.17 No command line thread: 747
Like I said above, in v2.17, using a thread for the command line is the default so that ESC and Shift-ESC will work. If you turn off command line threads, you will gain a small performance boost if you are entering complex scripts on the command line, but you will lose the ability to abort the script with the ESC key. |
|
|
|
|
|
|
|
