Events versus Python - Speed test?

I've just written an algorithm using Construct Events that manipulates a huge array (around 4.8 million items of data), and it works beautifully, taking around 2 minutes 18 seconds to complete.

Now, I was about to write the same algorithm in Python just to compare the speed, and I came across a couple of threads here that may mean I'd be wasting my time.

First of all, I noticed a conversation from last year where there was talk of the speed difference between events and Python, and it seemed that events were thought to be faster (if that's true, well done Ash & Co).

Secondly, in another thread, someone mentioned that Python couldn't access Construct arrays directly, and the overhead of the workaround would mean that it would lose any speed advantage you may have gained.

Now, I realise that this place has gone pretty quiet again, but I thought I'd ask anyway.

Anyone have any further insight into this?

Krush.

Well, when you use Python, the entire script is interpreted. However, with Construct events your script is running C++ compiled subroutines, which is incredibly fast compared to interpreted languages.

So with any Python vs Events choices Events will probably win out in performance (unless you are using advanced Python libraries, using different algorithms, or something along those lines).

Sadly, I haven't tested this out myself yet, so I can't prove it.

Unless your Python script is interacting with Construct during the process I would say it should be about the same, but 4.8 million is a lot......

Thanks guys.

Yeah, Python would have to interact with Construct, in as much as it would be reading and writing to the array that is being used by Construct.

The post that I mentioned concerning Python not being able to access arrays directly was quite a while ago, so I'm wondering if it was fixed in later versions.

Then again, we don't really know when the original devs stopped working on C1, so it's probably as it was.

And yeah, it's a lot of data, and I'm happy with the speed.

I can't optimize the events any more than I have, so I would have taken a little increase in speed if it was on offer via Python.

Krush.

As always I defer to ROJOhound for the hard problems..

but if Python did integrate with Construct arrays, I would believe that it could potentially be a lot faster using the Numpy library which at its core is all C/C++. You can also inline C code inside a Python script using Numpy.

http://www.scipy.org/PerformancePython

Excerpt from the site for a speed comparison:

Here are some timing results for a 500x500 grid for 100 iterations. Note that we also have a comparison of results of using the slow Python version along with Psyco.
Type of solution
Time taken (sec)
Python (estimate)
1500.0
Python + Psyco (estimate)
1138.0
Python + NumPy Expression
29.3
Blitz
9.5
Inline
4.3
Fast Inline
2.3
Python/Fortran
2.9
Pyrex
2.5
Matlab (estimate)
29.0
Octave (estimate)
60.0
Pure C++
2.16

[/code:x96idh12] 

My guess is right now they are not integrated enough, but I think it would be well worth it to add that support.

As always I defer to ROJOhound for the hard problems..

but if Python did integrate with Construct arrays, I would believe that it could potentially be a lot faster using the Numpy library which at its core is all C/C++. You can also inline C code inside a Python script using Numpy.

http://www.scipy.org/PerformancePython

Excerpt from the site for a speed comparison:

> Here are some timing results for a 500x500 grid for 100 iterations. Note that we also have a comparison of results of using the slow Python version along with Psyco.
Type of solution
Time taken (sec)
Python (estimate)
1500.0
Python + Psyco (estimate)
1138.0
Python + NumPy Expression
29.3
Blitz
9.5
Inline
4.3
Fast Inline
2.3
Python/Fortran
2.9
Pyrex
2.5
Matlab (estimate)
29.0
Octave (estimate)
60.0
Pure C++
2.16

[/code:29h149ni] 

My guess is right now they are not integrated enough, but I think it would be well worth it to add that support.

Those values show that Pure C++ still processes way faster than any form of Python, so Events are probably still better performance-wise. I say this because once the interpreted command to start the loop begins, Construct is running pure C++ during the loop (at least, that's how I think it works, I haven't had a chance to look at the source yet).

I think they shouldn't be too different, they're both interpreted at runtime, as far as I know. a construct action gets interpreted and calls a c++ function, or a python command gets interpreted and calls a c++ function. if you're talking about doing everything within python that a plugin does after being called, of course the c++ should be much faster.

these fps's would change within a hundred or so sometimes when run multiple times:

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/1.JPG">

2152 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/2.JPG">

2150 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/3.JPG">

1995 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/4.JPG">

50 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/6.JPG">

18 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/5.JPG">

20 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/8.JPG">

75 fps

<img src="http://dl.dropbox.com/u/1013446/New%20folder%20%285%29/7.JPG">

75 fps

Some interesting reading there.

Thanks guys.

Those FPSs are particularly interesting Lucid.

Especially the loops.

My data is manipulated within nested loops, with the arrays written to and read from a lot, based an several factors, so it's hard to say whether Python would be faster or not.

If I could have a definite answer as to whether arrays are directly accessible from Python or not, I could either test it in Python or just give up and be happy with the results I get from the events.

Krush.

I did a quick test and looks like Construct events are going to be ALOT faster. It doesn't surprise me because since we have to use a Construct array then you have to use the Construct call to populate the array and I don't see a way to use Numpy and Python tricks for performance speedup.

Filled a 2000x2000 array with int 5.

In Python:

start = time.clock()
for x in xrange(1,2000):
   for y in xrange(1,2000):
      Array.SetAtXY(x,y,5)
end = time.clock()
final = end -start
Text.SetText("Final time: " + str(final)) 

[/code:3cnb83ic]

In Construct just use two named loops, the inside loop a subevent to the first.

Basic Python w/ range(): 20.40
Python w/ xrange(): 20.19
Construct For Loop: 2.28

I didn't bother to check the performance for Numpy array generation with a Python array, but either way 2.28 seconds is hard to beat.

Thanks for taking the time to do that test Dave.

I think we can conclude that, at least with it's current implementation in C1, Python is no match for Construct's events.

Thanks again guys.

Now I can concentrate on the next stage.

Krush.