Oolite Bulletins

Scripting languages have very many obvious benefits: rapid prototyping, no "compile - edit - run" cycle, generally higher level with many convenient builtins (garbage collecting) than C/C++.

But they have a major problem for use in an interactive highly compute sensitive environment: they're SLOW.

Has anybody given thought to how to optimize OXPs? Maybe implement a true loadable DLL interface as well as a scripting interface?

Maybe (much longer term) the prolific OXP authors could note the sort of things they do over and over again in their OXPs and over time the common code could be factored out into the compiled core of oolite and made available to OXP writers to script, but then the meat of the code would run at native speeds....?

In my opinion, JavaScript is quite good in speed terms for what we are using it in Oolite. Much faster than the legacy system, at least. Making the scripting interface a loadable DLL is an idea, but it has two drawbacks that I can immediately think of:
1) It would require a major rewrite of the existing scripting code base. Just when we have managed to establish a flexible and stable scripting system, we would have to start all over again. One would ask "why not design it like this from the beginning?". Which brings me to the second drawback.:
2) This solution cuts down on portability. DLL loading is fine with Windows, but what about Linux and Mac? One of the principal goals of Oolite is to have a common codebase to build for all supported architectures, with as little platform-specific code as possible. Going the way you suggest would probably mean that we would need different code for handling the shared library containing the scripting system, depending on what architecture we run on. And then, if another port comes out in the future, new code would have to be written for it as well. Not very good in terms of maintainable code, I think.

Yeah I forgot about multi platform, I only have intel pcs . So forget DLLs.

But perhaps there is an opportunity for refactoring. JavaScript should not be used in general for very performance or memory intensive tasks. If there are such tasks being used in OXPs repeatedly, maybe that's a good sign that the (portable) core should implement the functionality (with caching so that when one OXPs asks for the data, it's generated only if invalid, then all other OXPs don't pay the cost of generating the data while the data is still valid), and then OXP authors who want better performance could recode to the new, faster interface.

Then again maybe all the performance problems I see are really related to known issues in 1.71.2 and the OXP performance is OK.... but I can forsee that with many OXPs loaded simultaneously, each one wanting to check certain information, that could make things slow.

another_commander wrote:

1) It would require a major rewrite of the existing scripting code base. Just when we have managed to establish a flexible and stable scripting system, we would have to start all over again. One would ask "why not design it like this from the beginning?". Which brings me to the second drawback.:

Not really. Just subclass OOScript and Bob’s your uncle. You’d almost think someone had designed it with this possibility in mind. ;-)

But no, I don’t intend to go that way. Partly because of portability, partly for security, but to a large extent because there’s just no need. OXP scripts aren’t a major source of slowness, even when they do nasty stuff like call scriptActionOnTarget: (the unpredictable side effects aspect is a bigger problem than the slow aspect, really). Scripts rarely run more than once every few seconds; if they were really a performance issue it’d be noticeable through stuttering rather than low overall performance. (The big opportunities for optimization in Oolite are in graphics, particularly frustum culling and better HUD rendering.)

Besides, implementing high-level game behaviours in scripting languages has been normal for years now. Large parts of Civilization IV and Eve Online are written in Python. Crysis, Vendetta Online and World of Warcraft use Lua for missions and/or UI scripting. If I continue working on Oolite beyond the next stable release, moving more high-level behaviours to JavaScript is a likely direction.

There don’t seem to be many games using JavaScript (apart from all the Flash games written in ActionScript, of course), but it has turned out to work rather nicely. It isn’t amazingly fast, but there is active, competition-driven development there. I expect we’ll be able to upgrade to Tamarin/ActionMonkey (effectively the Flash just-in-time compiler wrapped up in SpiderMonkey APIs) next year. Apple’s/WebKit’s SquirrelFish engine is currently faster than Tamarin, but I don’t expect Adobe and Mozilla will take that lying down.

Ahruman wrote:

...and Bob’s your uncle.

You know, it's amazing what Swedish language schools are teaching nowadays...

JohnnyBoy wrote:

Ahruman wrote:

...and Bob’s your uncle.

You know, it's amazing what Swedish language schools are teaching nowadays... :D

I wouldn’t know, I learned my English in Swaziland.

It could have been worse (?), I could have said “…and Bjorn Stronginthearm’s your mother’s brother”.

Ahruman wrote:

It could have been worse (?), I could have said “…and Bjorn Stronginthearm’s your mother’s brother”.

Call me Terry P. :-)

Ahruman wrote:

I wouldn’t know, I learned my English in Swaziland.

It could have been worse (?), I could have said “…and Bjorn Stronginthearm’s your mother’s brother”.

I really was only joking, Ahruman. Your English is so impeccable, I wasn't sure if it's your mother-tongue. So I fully expected my 'language school' joke to fall flat on its face...

Bob must get around a bit

TGHC wrote:

Bob must get around a bit

Bob's dad was somewhat promiscuous in his early years. The Child Support Agency have been trailing him for years.....

Captain Hesperus

Captain Hesperus wrote:

TGHC wrote:

Bob must get around a bit

Bob's dad was somewhat promiscuous in his early years. The Child Support Agency have been trailing him for years.....

Dad? Sibling, surely?