Speed test. Sadscript vs. Hardcode

[Robin]

I've been looking around for scripting capabilities within a VB6.0 application, and decided to run a speed test on Sadscript vs. Hardcode.

[http://www.freemmorpgmaker.com/files/imagehost/pics/eb287458716862ffc07348d462ec8bde.rar](http://www.freemmorpgmaker.com/files/imagehost/pics/eb287458716862ffc07348d462ec8bde.rar)

I took the documentation from the original Sadscript (Which I was disappointed isn't properly credited within Eclipse) and then used Eclipse's versions of the class files.

Change the hardcode manually, and load up any subs you want to test from main.txt

Post any custom scripts checked here, or any speed tests for the default code I posted.

Thanks,
_Robin_

[Robin]

Remember to compile the application for full speed.

Here're my own results:

```
Sadscript[1]: 579
Sadscript[2]: 562
Sadscript[3]: 563
Hardcode[1]: 31
Hardcode[2]: 47
Hardcode[3]: 31
```

[Guest]

My results
```
Sadscript[1]: 313
Sadscript[2]: 297
Sadscript[3]: 297
Sadscript[4]: 296
Sadscript[5]: 375
Sadscript[6]: 297
Sadscript[7]: 313
Sadscript[8]: 390
Sadscript[9]: 297
Sadscript[10]: 297
Hardcode[1]: 47
Hardcode[2]: 47
Hardcode[3]: 31
Hardcode[4]: 47
Hardcode[5]: 31
Hardcode[6]: 47
Hardcode[7]: 31
Hardcode[8]: 47
Hardcode[9]: 47
Hardcode[10]: 31

```
Do you want to kill the scripting part altogether?

[Admiral Refuge]

Ooo, can someone want to test this with my [#include main.txt](http://www.touchofdeathforums.com/smf/index.php/topic,44071.0.html), and prove if it really makes things go faster?

[Guest]

didnt work

[Robin]

I find it funny that you're advertising that it'd speed up your server when it'll have no effect at all.

In fact, the extra File I/O will probably slow down the initial load of the script.

I suggest you test something before claiming such things.

As for testing that script out personally, it's impossible. The amount of access to the script is simply too much to place a timer on all of it.

The best I could do is try out a filled main.txt with my called subroutine placed at the bottom. The results were the exact same speeds posted here.

[Robin]

I tested the basic script loading again.

Remember, I'm loading up a server (non-eclipse) as well as the script files here.

**Loading full default Eclipse main.txt:**
4681ms.

**Loading your #include based main.txt:**
4371ms.

**Loading empty main.txt:**
3562ms.

I did 3 small runs and averaged out the loading times. I haven't taken in to consideration any possible variables other than the script loading, although a lot more was going on at the time.

Obviously, a small .txt file is much more easier to parse in the original loading, ie. server load up. After that, all the script is stored in memory, so there isn't any difference at all between loading it all from one file, or from a few files, other than easier editing.

[Devogen]

Cmon guys, timing scripts is a little anal.

[Robin]

I'm not testing the speed of scripts against other scripts, I'm finding out what kind of overhead is experienced when loading from script rather than from hardcode. I'll gather up the average times, then test them against other types of scripting.

[Fruitpunch]

what version are you testing this for?

[Devogen]

@Robin:

> I'm not testing the speed of scripts against other scripts, I'm finding out what kind of overhead is experienced when loading from script rather than from hardcode. I'll gather up the average times, then test them against other types of scripting.

I gathered that mate… Im just wondering if the minute difference is enough to warrant the time spent doing so.

Speaking for myself only,  I'm not really fussed as the difference would be so negligable on my quad core, its not an issue that really concerns me, perhaps users that are still running 486sx processors and windows 3.1 might find it useful :)

[Robin]

@[G2D:

> УV☼ link=topic=45592.msg463026#msg463026 date=1243981008]
> I gathered that mate… Im just wondering if the minute difference is enough to warrant the time spent doing so.
>
> Speaking for myself only,  I'm not really fussed as the difference would be so negligable on my quad core, its not an issue that really concerns me, perhaps users that are still running 486sx processors and windows 3.1 might find it useful :)

I just like to like to know the ins and outs of things before I start working with them. In the end, you're right, the speed differences will be negligble, but I don't see the harm in doing a bit of background research before settling for a system I'll be spending a considerable amount of time developing.

[Admiral Refuge]

@Robin:

> I find it funny that you're advertising that it'd speed up your server when it'll have no effect at all.
>
> In fact, the extra File I/O will probably slow down the initial load of the script.
>
> I suggest you test something before claiming such things.
>
> As for testing that script out personally, it's impossible. The amount of access to the script is simply too much to place a timer on all of it.
>
> The best I could do is try out a filled main.txt with my called subroutine placed at the bottom. The results were the exact same speeds posted here.

The reason I was making those claims, was because it was tested.
Ambard tested it (he replaced his with this one), and it sped up his server (for instance, when it use to take about 30 seconds to login, after he added my version of the main.txt, it was instantaneous, and when reloads took about 1 minute, it does it instantly now).

Of course, he has a 350kb main.txt, but still, he said there was a very big difference in server speed and performance after replacing it.

[Homicidal Monkey]

Using Java engine (Windows XP SP1 1.8ghz x2 1gb ram):
Load time[0] = 0.275104603 seconds
Load time[1] = 0.284728124 seconds
Load time[2] = 0.27154467000000004 seconds
Load time[3] = 0.287916133 seconds

Script[1] = 21.258018912 seconds
Script[2] = 21.182469455 seconds
Script[3] = 21.200423839000003 seconds
Script[4] = 21.280592062 seconds

Hard Code[1] = 0.323642606 seconds
Hard Code[2] = 0.337203018 seconds
Hard Code[3] = 0.29862019700000003 seconds
Hard Code[4] = 0.34148369 seconds

Using vb6 engine
Hard Code[1] = 0.64 seconds
Hard Code[2] = 0.64 seconds
Hard Code[3] = 0.64 seconds
Hard Code[4] = 0.657 seconds

[Devogen]

I suppose sure if your script is getting above that 300-400k mark it would make a difference.

HM… 21 seconds to load a script? did i read that right?

[vrage]

@[G2D:

> УV☼ link=topic=45592.msg463264#msg463264 date=1244009694]
> I suppose sure if your script is getting above that 300-400k mark it would make a difference.
>
> HM… 21 seconds to load a script? did i read that right?

I'm wondering the exact same thing..

[Robin]

@Admiral:

> The reason I was making those claims, was because it was tested.
> Ambard tested it (he replaced his with this one), and it sped up his server (for instance, when it use to take about 30 seconds to login, after he added my version of the main.txt, it was instantaneous, and when reloads took about 1 minute, it does it instantly now).
>
> Of course, he has a 350kb main.txt, but still, he said there was a very big difference in server speed and performance after replacing it.

Hey, I'm not saying people won't find any speed improvements at all, I'm just saying that I've found no proof of this.

The loading speed difference between your version of the scripting is 0.3 second, and that's with a 22kb file. If someone's loading a 220kb, that'd still only be 3 seconds, so I honestly have no idea how it'd speed up loading time by a minute, unless Ambard is just seeing speed improvements which aren't there.

Of course, this is all in testing conditions. There will always be variables which I can't take in to consideration.

Besides, I prefer your way of loading scripts as it's so much easier to edit.

[Homicidal Monkey]

@[G2D:

> УV☼ link=topic=45592.msg463264#msg463264 date=1244009694]
> I suppose sure if your script is getting above that 300-400k mark it would make a difference.
>
> HM… 21 seconds to load a script? did i read that right?

oh yeah, this was a conversion/adaptation to the code that robin posted. The speed difference is caused only by the compiler and possibly the way it first opens the scripts.

btw, you can crank more speed out by using "JScript" instead of "VBScript". "JScript" tends to run faster because the interpreter happened to have been written better or something.

[Richy420Rich]

@Robin:

> Hey, I'm not saying people won't find any speed improvements at all, I'm just saying that I've found no proof of this.
>
> The loading speed difference between your version of the scripting is 0.3 second, and that's with a 22kb file. If someone's loading a 220kb, that'd still only be 3 seconds, so I honestly have no idea how it'd speed up loading time by a minute, unless Ambard is just seeing speed improvements which aren't there.
>
> Of course, this is all in testing conditions. There will always be variables which I can't take in to consideration.
>
> Besides, I prefer your way of loading scripts as it's so much easier to edit.

Well, Ambardia does have a 350kb+ main.txt and when we would reload scripts, it would take atleast 30-40 seconds, within this time, players get kicked off the server, packet flooder goes nuts, and some codes weren't even being recognized, like the reload didn't even load the whole main.txt. When I implemented the #include and seperated the main.txt. there was indeed a speed improvement when reloading the scripts, also it loads the whole main.txt now, and players haven't been getting kicked and the packet flooder hasn't went nuts since, and it reloads almost as soon as you click reload. So, as for Ambardia, the #include has helped quite alot. I also found myself before using #include, to place alot of the subs in the clscommands to drop the size of the main.txt, which also just helped to drop the size and allow faster reloads. Now it could be simply because the pc the server is on is rather slower then most, that could be the case in our situation.

As for the sadscript vs hardcode, I would have to say hardcode, however it's a pain in the ass to constantly update server or client hardcodes and depending on how much you're updating at a time, it might drive your players crazy. Sadscript is an easier way to make updates without much of a problem and once awhile, you can take codes out of Sadscript to implement into hardcode and do it on a routine like that.

[xeross]

if we had precompiled sadscript i think it would improve the speed.

[Robin]

@Richy420Rich:

> Well, Ambardia does have a 350kb+ main.txt and when we would reload scripts, it would take atleast 30-40 seconds, within this time, players get kicked off the server, packet flooder goes nuts, and some codes weren't even being recognized, like the reload didn't even load the whole main.txt. When I implemented the #include and seperated the main.txt. there was indeed a speed improvement when reloading the scripts, also it loads the whole main.txt now, and players haven't been getting kicked and the packet flooder hasn't went nuts since, and it reloads almost as soon as you click reload. So, as for Ambardia, the #include has helped quite alot. I also found myself before using #include, to place alot of the subs in the clscommands to drop the size of the main.txt, which also just helped to drop the size and allow faster reloads. Now it could be simply because the pc the server is on is rather slower then most, that could be the case in our situation.
>
> As for the sadscript vs hardcode, I would have to say hardcode, however it's a pain in the ass to constantly update server or client hardcodes and depending on how much you're updating at a time, it might drive your players crazy. Sadscript is an easier way to make updates without much of a problem and once awhile, you can take codes out of Sadscript to implement into hardcode and do it on a routine like that.

The way the script loading works is probably the cause of all this.

When the script is initially loaded, the entire text file will be parsed and seperated in to globals, subs and functions. All of this is done within a single subroutine, causing the rest of the server to "stand-by", as it were. #Includes are called through seperate subroutines, allowing the rest of the server to be given some breathing room to handle all the commands and packets which'll have stacked up if the code was loading at one time.

This isn't a problem with Sadscript itself, which you can find here:
[http://www.pscode.com/vb/scripts/ShowCode.asp?txtCodeId=36716&lngWId=1](http://www.pscode.com/vb/scripts/ShowCode.asp?txtCodeId=36716&lngWId=1)

It's a problem with how Sean originally set up the scripting system in Konfuze, which is the system Eclipse still uses.

My speed tests can't pick up on any of the problems you will experience whilst using the current Sadscript system in 2.7 and earlier versions, as the server I created to do the tests uses a modified system which is threaded.

I'm not up-to-date with the current staff on Ambardia, but I'd tell whoever is editing the engine to have a look through, and update, the Sadscript system. Eclipse doesn't handle it very well by default.

EDIT:

For those who care, I started up this speed testing to test out HM's post on the scripting speeds in 3.0 and 2.7.

@Zetta:

> EE2.7 SadScript
> runs at 1/80,000 speed of hard coded functions

From what I can see, that figure is way off.

What kind of tests did you do to come up with this figure, HM?

[damian666]

so, how hard or easy would it be to update sadscript i wonder?

make it better?

Damian666

[Robin]

Hard and easy are very relative terms.

As Eclipse's community is based around scripting and game development, rather than programming, it'd be hard for most people to even understand the class files from Sadscript.

Personally, I'm not sure. I've been talking to a few people who've had experience in the matter, and we're discussing pre-compiling it into more managable code, rather than re-parsing everytime the server loads the scripts.

I've also been wondering about client-side scripting. At the moment, as far as I can tell, the client can only be controlled via scripted packets. I would want pre-compiled scripts to be sent the client in encrypted byte arrays so it could handle scripted rendering and processing.

I'm not going to reveal much about what I'm working on until I talk to Marsh about it, but I did a basic test on how scripted rendering would go.

Here, I loaded the Processmovement, DrawPlayer and DrawNPC subroutines from a script. As you can see, the code now handles y-based rendering, dynamic sprite sizes with RMXP resource layout support (Allowing you to load the RMXP character sets as they're packaged in RMXP) and it also allowed me to change the Run_Speed and Walk_Speed to a number which isn't a factor of 32, as I added a catch-all xoffset and yoffset code.

Of course, there's a depremental effect to the FPS by loading a script file every loop, something I'm hoping I can bypass sometime in the near future.

I can probably get the FPS back up into the 900's if I convert the rendering routine to pre-render the map to a set of buffers.


[damian666]

hmm… that sounds and looks frikking cool man, i do hope you can share some
of your great ideas and coding skills to make the last VB6 eclipse the best one there
has ever been.

i dont knwo about others, but i am not moving to java version, i dont want to learn all over >.<

and yeah, i agree, i think the classses of sadscript look very hard, i downloaded from that link, but i cant even imagine where to start :o

well, thank you for the explanation and that cool screenshot :)

Damian666

[Robin]

@Damian666:

> hmm… that sounds and looks frikking cool man, i do hope you can share some
> of your great ideas and coding skills to make the last VB6 eclipse the best one there
> has ever been.
>
> i dont knwo about others, but i am not moving to java version, i dont want to learn all over >.<
>
> and yeah, i agree, i think the classses of sadscript look very hard, i downloaded from that link, but i cant even imagine where to start :o
>
> well, thank you for the explanation and that cool screenshot :)
>
> Damian666

No problem. The whole point of what I'm doing is so that those who wish to stay with VB6.0 and DirectX7 can do so.

I haven't got any kind of permission from Marsh yet, but I'm hoping to re-work the older systems in to a more scalable, modular environment.

I'll post some more information once I actually get the go-ahead. In the end, this might come to nothing.