Mass Benchmarking Required

nice work. good to see this has been useful anyhow.

@Ivand, some new software can become faster, like Window 8

Window 8 is recommended to be installed on old PC because its fast.

"A Fish with bicycle wheels? Hell, this upgrade is automatic, it's systematic, it's hydromatic. It will turn your old PC into Greased Lightning." - http://www.zdnet.com/article/installing-windows-8-on-your-old-pc-could-turn-it-into-greased-lightning/

(Whenever I say I in the following post, I mean to say "I with the help of Anarchid and ikinz ")
https://docs.google.com/spreadsheets/d/15dq0EuuhB29ezifaOQIu2PMpR9T7hbpeGGmgqMPGACI/edit#gid=0

I suspected the all round fall in performance, especially in the event may be the result of lua not getting optimised as much as it did in 91.0 as apparently the liblua glue code was changed a bit.
So I've compiled a 98.0 version with 91.0's lua (and some small fixes to make it actually compile).
First result was a significantly larger file size, probably due to inlining of lua functions that now actually works.
Second result can be seen in the benchmark under 98-frankenlua (it's better than both 98 and 91). It's indeed only one run, I'll conduct more, but mild optimism may be in place.

EDIT:
diff is here:
https://gist.github.com/ashdnazg/007390d11354c8ed723a

EDIT 2:
I was wrong about inlining I think, but I'm pretty positive the lock that was added affects the performance significantly

EDIT 3:
https://gist.github.com/ashdnazg/8ef5721ea9ff91883bf9
This seems to be the thing that affected performance the most.
I suppose there's a reason for a lock, so it can't just be removed, but that's where we should concentrate to have the largest improvement.

EDIT 4:
Just had some tests, and I've managed to play 1v1 with one client having develop version and one develop+patch. Haven't encountered desyncs. Also managed to view replays of one with the other with no desyncs.
I think the lock is there to allow lua to run jobs in parallel, but that never actually happens in the current engine design, so we're just wasting lots of cycles with no (apparent?) gain.

LuaJIT was tried in the past and no measurable improvement was found.

Pxtl,

Maybe, but I'm not sure that justifies the potential costs. Building luajit is sometimes non-trivial, and last time I checked it has problems building on some platforms. There's a lot of good things to say about luajit, but none of them will trump measurements imo. With luajit, it's usually either a big win or a waste of time. The projects I've used it on had most of their expensive logic written in lua, so luajit integration was massively profitable (calling into our C api became the bottleneck). A full RTS engine is a different story, much of the expensive logic is likely in C++ (could be exposing my ignorance here), especially things like pathfinding and physics simulations. In my experience, these two are the most likely culprits, given that luajit integration has already been measured, and they wouldn't be affected by luajit in anyway.

Your first instinct should be to make a pull request.
From a layman's point of view this looks like a legit change, so I don't see why not...

We can build engine ourselv of course.
Best if you could manage to build multiplatform syncing win/linux pair together with spring-dedicated.exe ..all we need then is to zip it and let Licho know :)