Re: GC stall in luaC_separateudata

[Niklas Frykholm <niklas@...>]

Thomas Harning wrote:
> Niklas Frykholm wrote:
> > Most of these objects come from arithmetic operations on vectors 
> > (which are represented as userdata objects), so my best idea right now 
> > is to change that to a table representation, which would mean fewer 
> > userdata objects (possibly at the cost of performance).
> A solution may be to setup an object-recycling/pooling system so that 
> you can 'release' a vector and re-use it later.  This would involve 
> manual object management, but could be a performance savior.

Yes, that would drastically reduce the ammount of objects that need to 
be collected. I guess it could be done in some different ways:


1. Operations default to returning temporary objects

self.v = (self.v - dot(x, self.v)*x):normalized():save()

save() converts from a temporary object to an object for long-term storage

+ can write expressions using normal syntax
- fragile -- forgetting save() will give weird bugs


2. Operations default to returning permanent objects

self.v = (self.v - (dot(x,self.v) * x):free()):free():normalized()

free() frees the object for reuse in the next frame

- expressions become harder to read
? less fragile? -- maybe not, it is easy to forget a free() or to put
  in one free() too many
+ free() can be added to the code base one at a time, less of an
  all-or-nothing approach


3. Operations on temporary objects return temporary objects, operations 
on permanent objects return permanent objects -- mixed operations are 
forbidden

self.v = ( self.v:temp() - dot(x,self.v)*(x:temp())):normalized():save()

- not very readable
? less fragile? -- precense of temp() is reminder that you need to
  save(), forbidding mixed operations will detect some bugs
+ can be introduced gradually
- unclear how it should handle functions on C side that return objects,
  should they return permanent objects or temporary objects... or should
  there be two versions of every function


I can't say that I like either option that much, but if there is no 
other way, I may have to go there.

Still, I think I need to switch to tables anyway, because as far as I 
can tell, it is not just the collected objects that is causing the 
problem. Just processing my base set of user data objects (30 000 or so)
seems to come with a latency/stall of 3-4 ms which probably is too much.

// Niklas