Quote:
|
Originally Posted by c0ldfyr3
Hey all.
I was just browsing mattie.info, and I cant help but notice the amount of people creating scripts...
Am I the only one who sees a problem with using scripts instead of plugins ?
|
Nah, but coders worry about this more than admins do. We just don't think about it the right way. Performance is both (a) not as important as we would think and (b) not affected as much by these scripts as we think.
Do plugins perform faster than scripts? Obviously-- by leaps and bounds! But the question is not "which is faster". Instead, for the vast majority of people the question is:
- Do I get the functionality I want and still get the performance I need?
This is a lot like arguing against a higher-level language. Think about it this way: is Java worthless because it performs slower than C++? What about VBScript? JScript? PHP?
No-- they all have their usefulness. Yet if you're doing something mission critical that needs every millisecond, you're going to stick with ASM or C/C++. The number of cases where this is necessary is far fewer. Otherwise every website in the world would code their dynamic pages in C-- yet here we are conversing over a scripting-language-enabled website.
Even full plugins are necessarily slower performing than a server without them. Yet people still add those, too. It's just a trade-off, and you trade-off what you can afford.
And you don't even know what performance issues might be there-- why don't you try it? It's very easy to configure. That's a common recommendation in coding: generally, it's best not to jump through hoops optimizing performance until it affects you. If it doesn't perform well enough for your needs, optimize the bottlenecks.
And you'd be surprised, anyway. If the performance was so bad, EventScripts never would have gotten popular. For example, I have a large number of scripts (including player_hurt spam) on my beta test Windows CS:S server. It's not the best performing server, but it plays well enough to have regular players-- and it's running on an old AMD Athlon 2000 which is also running, like, 15 web servers (including mattie.info, wikis, etc). My other beta test server is on nice hardware running at 66-tick. It supports far more scripts and generally has very solid performance.
In the end, a few scripts don't matter for performance for the average players. It really doesn't impact things as much as you think.
As to why there are so many of these scripts being created, that's pretty clear. The whole point for EventScripts is not for coding full-fledged plugins, but to let people customize their servers easily. Why in the world does someone need to know C++, how to build on Windows and Linux, virtual function hooking, and the Source SDK just to customize their server? Why must an admin have
no option just because it doesn't perform as well as if he learned C++ and coded it from scratch or with metamod help?
Some people use it for more advanced things-- and more power to them. On powerful servers, even heavily scripted gameplay can be fine. I would never recommend people do that for anything too serious. As ichthys says, I can't imagine I'd play competively on a server that was heavily modded with scripts. Yet for a fun mod (we're talking about games here, afterall), a little extra reduction in responsiveness spread equally around is just fine.
Scripts are popular because it is far, far, far easier to create a cfg file that works across platforms than it is to write a plugin to do so. Zillions of admins with some knowledge of computers vs. perhaps a hundred or so coders who would be interested in writing plugins.
Let's breakdown the performance weaknesses compared to a plugin:
- Valve command console/queue handling
- Script interpreting (conditions/variable expansion/etc)
- Console commands parsing
- exec file access
#1 runs inside the server-- this can affect performance because the command queue can only be consumed at a particular point in the GameFrame. I don't feel that this substantially affects anyone on a level that players would notice. Small hit, really.
#2 costs a bit more, but this is all handled inside a server plugin which we're already assuming is pretty fast. This is the general cost associated with a higher-level scripting language. I.e., the interpreting overhead costs something. This is the 2nd biggest hit, but is a welcome trade-off for having cross-platform support without understanding C++/pointers/etc. There are different ways to optimize your scripts such that the biggest performance bottlenecks minimize the interpretation impact (e.g. only making a few passes through the variable expansion engine, etc).
#3 isn't actually an issue since these commands are basically taking advantage of the code inside other server plugins or the server itself. These are very light and can commonly map closely to what you'd do in the Source SDK anyway in a function. There's some overhead in parsing the params/etc, but it's below the cost of #2 so it's not very troublesome.
#4 is where the real bottleneck appears. Loading a cfg file from disk every time an event fires? Wow-- that sounds like it could be expensive. Yet, it turns out to be very acceptable. Because of this issue, I never assumed that ES would see a lot of heavy scripting. Yet, with good OS file system caching and fast disk speeds, it's a little less than you'd expect.
The last, being the bottleneck, is where we work first. And people on Linux servers have already begun to map their entire event cfg directories onto a RAM drive to nearly negate this cost. And now they're running complex scripts on 64-slot high-tick servers!
The next version of EventScripts will have experimental support for changing exec to memory cache the cfg file and use that if the on-disk file hasn't changed. As such, we'll see this bottleneck reduced even farther and you'll see that in the common case performance doesn't even register as affected.
At any rate, I completely understand where you're coming from, because I wouldn't have expected EventScripts to get so much use. Yet, this is one of those situations where you just have to try it to see where it performs poorly for you. If it does, you write a plugin. If it doesn't affect things enough to warrant all the trouble, well congrats, you spent 5 minutes writing your own customization rather than investing in an entire plugin.
One last point I'll make is that I get
far more requests to add commands to EventScripts than I get to increase the performance. In my mind, that's the real test of how well it's performing for people.
Give ES a shot-- I'd love to hear your thoughts on its performance. I'm constantly working on ways to thin the lines between plugins and scripts, but obviously it'll never be perfect. I'm aiming for acceptable. ;)
-Mattie