1. Hey Guest, is it this your first time on the forums?

    Visit the Beginner's Box

    Introduce yourself, read some of the ins and outs of the community, access to useful links and information.

    Dismiss Notice

A couple of Qs on script loading, caching and performance

Discussion in 'Modding Help' started by Vermilicious, Sep 15, 2017.

  1. Vermilicious

    Vermilicious Ballista Bolt Thrower

    Messages:
    232
    In vanilla KAG, it is common to include a mix of different scripts in a Blob config file. At the same time, often scripts are included through directives in the scripts themselves. Is there any significant difference in performance between the two approaches in regards to loading and caching?

    And, if you choose to use the same script file for the different types of hooks, such as CBlob, CSprite and CMovement, for example, will the script be cached and read once, or several times? Basically, is there any significant performance difference in combining these types of script into one compared to separate ones?

    Are all scripts cached/compiled from the start, or are they read from disk when they are referenced and then cached/compiled?
    --- Double Post Merged, Oct 3, 2017, Original Post Date: Sep 15, 2017 ---
    I hate to be nagging, but since compiling, building and downloading scripts and mods has been sort of a topic lately, can someone give a small indication here? :migrant:
     
  2. Asu

    Asu THD Team THD Team Forum Moderator

    Messages:
    1,580
    I don't think packing everything in a single script is a good idea. #including scripts basically directly includes them in the source where the preprocessor directive is, which means that if two of them expose the same hook, you will have a function that is defined twice within the same script, and it will fail to compile.
    One script will only be compiled once for sure, and it will be reused for all types of hooks. But again, it is not necessarily good practice to combine all scripts into one.
    Scripts are compiled when the player joins the game (i.e. at the 'loading blobs' and 'loading server scripts' screens or something like that for modded servers).
     
    Vermilicious and blackjoker77777 like this.
  3. Geti

    Geti Please avoid PMing me (poke a mod instead) THD Team Administrator Global Moderator

    Messages:
    3,730
    Definitely don't put hooks into includes (there's like 1 or 2 cases in vanilla where this happens and it' suuuucks for reuse).

    However, I've personally found that something like Mine.as is nicer to work with than MineAnim.as and MineLogic.as - you don't need to move any "common" stuff to an include or duplicate it. There's no difference in performance. Maybe a slight win in bandwidth usage? (cause a single bigger script will likely compress better, and there's maybe less likely to be code duplication). Doesn't affect how things are stored much though. It will only be compiled once but the compile time is really short per-script. The only possible downside is your script getting "very big" if you have a complicated object, but it's subjective whether you'd prefer lots of medium-sized files or one big one tbh.

    There's actually something coming Soon™ about caching that will help with performance, but it will also be unaffected by this decision. If something would benefit from combination in your eyes, go for it. If not, common includes are fine.
     
    Vermilicious likes this.
  4. Vermilicious

    Vermilicious Ballista Bolt Thrower

    Messages:
    232
    In vanilla script there sure is a lot of splitting up, and it's a hassle to review and debug.

    For blobs I usually only use blob and sprite scripts, and I use the latter only because it's a convenient way not just to split "visuals" from behavior and logic, but also because it's not run on the server. I call my scripts SomethingBlob and SomethingSprite to avoid any confusion. I do have some inheritance-like stuff going on though, and some intermediate boilerplate to provide a little more flexibility in mixing and matching parts of the code, so I have to keep in mind that I don't bloat stuff too much. I guess that's why I was asking these questions.

    The vanilla naming scheme is not to my liking. The worst is the "Common" scripts you mention, Geti, which often contain a crap ton of both constants, functions and class declarations. And includes. In addition to multiple scripts coupled with the blob, you have very many sources to look through to find what you need. If it's not provided by the engine, that is. There's no way to tell other than by experience or the lists in the Manual folder. It's typically said in regards to OOP (here we go again) that you always have to look elsewhere. In that regard, this way of organizing code is not much better. I always have to look elsewhere, and it's very annoying and time consuming. Some code is also split into unnecessarily many sub-functions, but at least it's in the same file.

    In regards to performance, well, if this was C++ I wouldn't be very worried, because the code ends up being compiled into pretty much the same few instructions anyway. All these constructs we write have little to no effect on the end result. It's all a matter of convenience. With AngelScript, however, I don't know enough about what the end result is and how these things might affect the outcome. As I understand from what others have said, the code is compiled into some sort of byte code (it's not an interpreted language), but other than that it's just guesswork. It has also been said that Angelscript is kind of slow.
     
  5. Asu

    Asu THD Team THD Team Forum Moderator

    Messages:
    1,580
    Angelscript is compiled down to bytecode, which is sort of a generic intermediate representation (there are a few differences between platforms you can find here, and here are the available bytecode instructions if you are interested). The compiler is capable of performing a few optimizations over the bytecode, I don't know how many are performed but they probably don't matter a lot. So, considering how things work internally, I don't think the way you organize scripts matters a lot. Though, the code never gets compiled into machine code. Instead, it is run through an interpreter, or VM crafted for the bytecode.
    This is what makes Angelscript fairly slow in comparison of a lot of "big languages". C, C++, Rust are directly compiled to machine code. JVM languages (such as Java) or Javascript are compiled down to a custom bytecode just like Angelscript is, however, their (popular) implementations are capable of compiling the bytecode on-the-fly as machine code. This is referred to as Just-In-Time or JIT compilation. Lots of other languages, especially scripted ones, does it the same way as Angelscript: Lua, Ruby and Python, for example. Note that the quality of the VM, of the compiler and how the language is designed means a lot in terms of performance, even if you would think they perform similar.
    There is actually a JIT for Angelscript which might have even been integrated into KAG at some point IIRC but there are a few reasons I forgot it isn't in today. Maybe it could be built in back, but there's already a huge room for improvement as for how KAG handles scripting. There are many mad things KAG does, for example the script callback for collapses is literally performed by iterating over every single script and tries to execute the hook over them. Let's say that this coupled with a bug that had the callback be called 6 million times on a large collapse didn't help with performance.
    As Geti said the cache (not the bytecode cache I was mentionning on discord a few days ago) might help eliminate some of that madness.
     
    Last edited: Oct 4, 2017
    Vermilicious likes this.
  6. Vermilicious

    Vermilicious Ballista Bolt Thrower

    Messages:
    232
    Right. I assume the people working on AngelScript is somewhat capable of making it relatively efficient. It's not exactly widely used though, I think. I might've wanted more detail than strictly necessary. Anyway, conclusion, I guess, is that the differences in how it's done file-wise is negligible.

    Yeah, collapse is noticable. I think everyone's noticed.