[FlyingMongoose]

The "Mani retired?" thread got locked, and 2 posts (1 by me and another by pimpinjuice) got deleted. (you can search for it on ES forums, just look for "SourceMod" it's first hit)

The thread went to the article recently posted on the SourceMod site that outlines performance hits comparitively of EventScripts and the still alpha software SourceMod. In the post regarding the article it was regarded as a "hit piece" claiming to be slagging on EventScripts, in essence, it really does not, it emphasizes that AlliedModders suggests against using it, but doesn't say not to do so. It points out performance flaws in EventScripts in order to provide a benchmark and comparison between the two. In my argument I posted I validate the arguments in the article, and provide a personal experience that I have had with EventScripts.

The arguments against the SourceMod article claim that the EventScripts were not properly optimized, so without further adiu, here is my rebuttal.

I'm going to point out that while EventScripts *CAN* be optimized, it can not be optimized to the level of SourceMod in any way, due to the number of limitations in the way it stores variables and executes functions. Also, that "hit piece" as you call it is pointing out milliseconds difference, not nanoseconds difference, which is a significant difference. There a number of performance issues in ES that the article points out. Also, EventScripts may be more popular to the less experienced in the scripting field, but the most you will gain is lessened performance and poorly built scripts on "pseudocode". A standardization is a significantly better way of applying the necessities of a scripting api, especially when utilizing an established scripting language. Allow me to give an example of my PERSONAL experience with EventScripts I ran 1 eventscript that all it did was check the mani variable mani_tickrate and output the value to the chat line. I was running mani, and nothing else at the time (other than ES), within 1 week and I got performance, ping, choke, lag, and registration complaints, 1 week. I'm also going to point out these are typical benchmarks and performance tests. Not something "beyond what any scripting language should do" Now , what the developers of SourceMod did offer is since the code examples used in ES were posted, that you go ahead and optimize it, the algorithms can't be changed, but if you optimize the scripts and supply them, they'll be happy to re-run the benchmarks.

I would like to expand upon the nanoseconds/milliseconds argument here and state that ping/latency operates on milliseconds. Now, wouldn't it be nice to have your ping at 50 nanoseconds as opposed to 50 milliseconds? Currently this is a physical impossibility, but it's an example I feel works. The same idea applies to command execution. It's much better to have a command execute in nanoseconds as opposed to milliseconds.

[API]

EDIT: I love everyone.

[FlyingMongoose]

PimpinJuice, that's not exactly the thing to point out when trying to AVOID flame-war

[awuh0]

I locked and deleted your flamewar because I don't appreciate you making a mess. Oh and feel free to try and start a flame war on steampowered we all know thats the correct place for this type of foolishness.

FYI:
Running 2000 math equations and saying sourcemod's better because it can flip bits faster is pointless. The purpose of any mod kit should be to make it easy for people to develop a mod not calculate pi to X digits, if it were we would all be using assembly.

[sslice]

It would have been 10000000 iterations but ES could barely handle 2000. Anyways, that's beside the point. The article was designed to point out the problems with using EventScripts for developing anything that is very complex. Some people consider EventScripts to be easier to develop in than SourceMod, while some think otherwise...but that is also beside the point. You cannot expect top-notch performance on your production game server while running EventScripts with any considerable amount of scripts (though this may not be important for many). I state this all in a generalized manner because there is no telling what affects the performance of your server. However, knowing you are getting the most out of your server both performance-wise and functionality-wise is the end goal for just about any server owner.

[BAILOPAN]

awuh0: Read the FAQ. Your argument is a fallacy (otherwise, benchmarks would have no meaning). 2,000 iterations in 2.5 seconds means ES takes 2.5ms to do a single math operation which is unheard of in any other language. When you have to start measuring single operations in milliseconds, there's a serious issue.

It seems the only response ES people can cough up is "it's easier so it doesn't matter," rather than "yes this is an issue and we should look into optimizing our implementation." Luckily, this is also covered in the FAQ. The article is not about how easy EventScripts is, it's about how poor the implementation is.

Whether EventScripts is easy to use is a matter of opinion and unrelated to the discussion. Nor does it change the fact that when you develop in EventScripts, you're instantly hitting a rock-bottom performance line, or the fact that these problems could be fixed without sacrificing the syntax.

See, this comparison would still be valid if we compared EventScripts to a language like PHP, or Perl, or Python (all of which are embeddable), because the performance is simply astronomically worse than what users should expect.

[FlyingMongoose]

Again, as I stated in the original post, these are basic and very common benchmark tests. EventScripts *should* be able to handle them in an efficient manner. But it does not. Plain and simple.

I do agree with your decision in deleting the thread on the ES forums, it probably would have made things far worse than they are, however, I did nothing more, in that post, than validate the benchmarks, and provide a personal experience. I did not "flame" ES. People jump to these conclusions significantly too fast in my opinion.

[Isias]

I'm glad to hear Sourcemod is beta now, but why are you telling awuh0 not to post about the features his plugin is capable to do, although a third person asked for a feature like this, but otherwise post on the Eventscripts Forum how poor the implementation of ES is and that ES looses highly in comparison to SourceMOD? Isn't this exactly the way of self-evangelizing you don't permit on your forum?

And after the post was deleted, it was started again here and of course this is, in some kind, dissasembling Eventscripts. Why was this comparison needed to be published at all if not to point out the advantage to Eventscripts?

[awuh0]

Bail the only bad thing you can find with evenscripts is that its not fast, and I have news for you, your one and only point happens to be false for the newer versions of eventscripts.

Thanks -<[PAGC]>- Isias, I'm glad someone notices how funny this is.

[sessus]

The SM vs. ES comparison and the accompanied 'test' are quite pitiful. I was quite excited to see all the development that happened around SM lately and thought that finally there will be a good product out there for HL2. All this flaming from the SM dev team, however, means:

- SM is clearly bitter about the success of ES, but what do you expect with a product being in pre-alpha for ages?!
- There are like 2 SM scripters and flaming seems to target the ES community to switch to SM

I think ppl here at SM should ask themselves: Does it matter that SM can calculate 1+1 quicker than ES keeping in mind that that is the only thing it can do at the moment?
Yeah this might be exaggerated, but this being a rhetorical question, it should show that SM should put their effort into development rather than testing of currently irrelevant aspects between two plugins.

- Grow up