llRezObject behaviour different with mono?

I have made a textwriter which rezzes a number of temp prims to write something.
Under LSL it works just fine, but when compiled under mono the object has problems rezzing temp objects after about 107 items... Recompiling under LSL cures the problem but loses the speed.
Anyone know if this is by behaviour or a bug in mono?

i did some more research.
I use a linkmessage to different scripts for rezzing the objects (bypassing the pausing).
It seems that mono is fast enough to create a lot of linkmessages which overflows the event handler. So it starts missing some calls to create a object.

Good for you

A word of caution, though. LSL has delays on these kinds of things to discourage us from doing them frequently because that would cause lag. Whenever we work around them, we need to have a good argument to justify it: either the resulting service is so important that we suffer the lag, or the flurry of activity is rare so it's not a big problem.

If your object rezzed the text once and it stayed for a good while, fine. But, given that the objects are temps, it means you have to rez them once per minute.

Sounds evil to me.

Use of temp objects is another red flag. Why use them? To avoid land prim limits. But the idea behind temps was that ... imagine this ... they would GO AWAY, so the extra usage would be temporary. Bullets are prime examples.

Temp rezzers are generally despised because they contribute to lag and use up a sim's allotment of temp prims (there is a limit, just not per parcel). And their purpose is to cheat: to make something permanent by using temporary objects. None of the advantages of temp objects apply: it's abuse. When used sparingly, not a big problem. They're only bad when they're popular.

It's too bad SL doesn't give us a sensible way to render text without jumping through hoops.

I ran into this same problem the other day with the listen event queue filling up too fast. Apparently, all event queues are limited to 64 events. In my case, I had a total of 71 events and managed to optimize things a little so that the 6 'extra' events were processed before the remainder of messages were received.

It would be nice if the event queue were bumped up to 128. It would also be nice if, when this happens, that some debug message is said instead the messages being silently discarded.

I had some similar problem in our Prim mirror for linked sets. The root script instructs all child scripts to mutate the child and then report back to the root, a handshake if you like. It failed for a 68 prim object.
The work around was to give each child script a different time offset = delay*llGetLinkNumber();
This way the root script does not get 67 acknowledges at the same time.

I thought we were up against the gray goo fence, but it may very well be the event buffer in MONO