Simon Linden suggested in Andrew Lindens office hour that because simulator is trying to do many things in single frame when rezzing objects (like add objects to sim, start scripts, enable physics, etc) - so that could be one thing to look for. He suggested that rezzing task should be multithreaded so that SIM is not blocked.

please - don't try to do "compatible" from C# with LSL - fix all bizarre bugs and go fully object oriented. Add somekind support for future version so that you can actually fix bugs without breaking content.

This is true, but I have three projects in progress right now that are severely crippled by the delays. An example being a HUD dungeon crawl game ported from VMS. The actual game runs in 3 scripts. Then it takes 38 more to make the map viewport even remotely interactive. >_>

It's a bit ironic that the constraints that were put in place to limit resource hogging by a single script, have ended up requiring people to use a ton of scripts instead to overcome the limits, thus not having the original desired effect.

Since a script maintains state when it is picked up into inventory, would it not be possible to persist the script state to disk when it is disabled and completely remove its VM instance or whatever it is from memory?

kernel swapping is fast... I wrote a MUD ages ago that just kept everything in memory and let stuff that was inactive page out, and it worked just fine on a box with 32 megs of ram and 1 G of swap space.

So with the limits not being enforced until the middle of next year, would it be a safe assumption that by that time, we'll have both C# and delay fixage, so I can quit worrying about angry clients attacking me with pitchforks? >_>