To script, or not to script (use events)

This forum is currently in read-only mode.
From the Asset Store
2D fighting template based in the game that defined the fighting games genre.
  • Hello! Still wrapping my head around this. Is there any performance increase\decrease based on if you're scripting or using the event system? I'm a .NET developer and I'm more inclined to start programming scripts for my functionality as opposed to playing with the event system.

    I tried to search for this discussion but it seems event and script are pretty common. Hope I'm not repeating.

    Thanks!

  • I'm not sure - Python isn't really famed for being a high performance language, and events are compiled C++ code but introduce the overhead of event processing. I don't think anyone's done realistic performance comparisons. What is it that you're trying to do? Is it fast enough?

  • just did 2 quick test caps that do nothing but loop, to test how much the actual event and python interpretation slows down

    i increased the loops for each python and events until it slowed the respective caps down to 29 fps.

    it seems the event interpretation is much faster

    events:

    1,450,000 iterations at 29 fps

    python:

    550,000 iterations at 29 fps

    in case someone can find a flaw in my methods:

    the event version was:

    <img src="http://dl.dropbox.com/u/1013446/mantis/Capture.JPG4.JPG">

    and python was:

    for i in range(0,550000):
    	pass[/code:2fy8zl5i]
    
    the reason I put the Always in the event version is because python doesn't allow you to make a 'for' loop without a statement in it, "pass" does nothing, but is still interpreted at runtime 550,000 times. so in order to even it out I put the always condition in there to be interpreted each iteration in the event version
    
    for the curious, without the always statement, the loop in the event system is able to iterate 10 million times before it slowed down to 29 fps
  • ...

    it seems the event interpretation is much faster

    ...

    The test isn't quite fair. I'm absolutely sure, that a for loop would be faster in Construct than in Python, but don't forget that range() is a function. You would need to setup a function in the event system, too.

  • I'd recommend setting up some simple tests that compare performance between the two in ways that matter to your application.

    In my own past tests, doing things like moving sprites around, python has been significantly slower than using events. However, you can mix events and scripts just fine, and that is what I often do.

    Python has some distinct advantages when you need complex data structures, and for re-usability of code, among other things.

  • Yes, definitely need to add a function call each loop.

    Also, your implementation in Python could be faster. Using xrange instead of range (of course wouldn't work with the large loop in this test since it i limited to Int) or using a map. I'm not a big enough expert in Python to know optimizaton down cold though.

    http://wiki.python.org/moin/PythonSpeed ... Tips#Loops

    For additional acceleration you could try Psyco: http://psyco.sourceforge.net/introduction.html

    Although, Pysco only works on 32-bit systems and has some other limitations... so maybe not the most practical.

    Another option is to use Numpy and other Python libraries that may be more efficient with calls like arange() If you don't mind the library load time... it "might" have a speed up.

    Now if I wasn't such a NOOB with Construct I would benchmark the two.. but can't seem to think of a good test.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • events:

    1,450,000 iterations at 29 fps

    python:

    550,000 iterations at 29 fps

    That's interesting, thanks for doing the measurement. Also, IIRC, Python doesn't evaluate the range(0,550000) statement every iteration in a for loop (otherwise it'd be even slower!), so a function call wouldn't even things up.

    I can explain why the For condition shows up as so fast: the per-iteration overheads of the loop conditions in Construct are actually incredibly low - comparable to the overheads of a C++ loop. The real work comes in the overhead of executing actions, conditions and expressions (each of which involve a for-each and execution of function pointers which are comparatively expensive for C++), as well as the list processing of conditions which pick from a list of instances. None of that is present in the events in your test.

    If it interests anybody, the For condition with no actions or subevents, in a release build, with a good branch-predicting CPU, effectively comes down to this:

    __int64 r = ...;
    
    // ...
    
    for ( ; r != end; r += step) {
    
        // (omitted some branches here which will be correctly guessed
        //  and have almost no performance impact)
    
        pCRuntime->pCurrentEvent = pThisEvent;
    
    }[/code:vc2hdvg8]
    
    As you can see it's simply a for loop with a 64 bit index that assigns a pointer every iteration.  This kind of thing takes literally a handful of cycles out of your 3 billion or whatever a second.  I'm kinda proud I got the overhead that low and it runs so fast 
    
    Adding an Always condition essentially adds a function call or two, and a call through a function pointer, which explains the reduction in performance.
    
    Making a fair test is tricky especially considering your framerate will largely depend on the rendering too.  I propose maybe doing some kind of processing on a bunch of say 1000 sprites, and write equivalents in Python and events and see which goes faster.
  • Yeah, my observation was that mixing python and Construct events results in a significant performance drop compared to using events or script exclusively. All those calls back and forth take a heavy toll.

  • Yeah I would guess there is some optimization you could do tho.

    Like loading all modules at the start of layout, use events for movement, etc.

    So basically, don't write a bullet hell with python....

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)