[sldev] Multithreading, Garbage collection, Caching

[David Fries]

On Sun, Mar 18, 2007 at 02:21:59PM +0200, Skal Tura wrote:
> I'm wondering that is anyone working on multithreading?

I did some quick research for you.  I started second life and saw that
it was taking 5 threads, though only two threads had any significant
amount of CPU time.  Note I'm compiling from source and don't have
fmod sound support, not available source for that.

> Garbage collection:
> It has started to seem that garbage collection is "somewhat" lacking, i see
> SL taking constantly
> more and more memory, and starting to run slower and slower each passing
> hour.
> Could someone clarify this, perhaps some numbers?

C++ doesn't garbage collect, but Second Life does do some refernce
counting.  Reference counting that I've seen works like this.  Derive
a class from the reference counting base class.  Each place that
needs a reference to the object has a reference object holder, if a
reference counted object is assigned to that object it will increase
the reference count, if it is unassigned it decreases the reference
count.  The holder also decreases the reference count when it is
destroyed either being an automatic variable or in another class.
When the reference goes to zero it is destroyed.

Nice, easy, automatic, explicit, and you don't have to constantly scan
memory like garbage collection systems do.  Ever seen a Java program
swap and stay there?  Even an idle java program will bring itself back
into memory just to garbage collect, yuck.

> Caching:
> Why for the ffs caching is done that badly? Asset server load could be
> easily cut to half if it
> would been done better!

What is ffs?

> Let's say i'm at place A, where i am very often, i goto place B, spend there
> 10minutes, and come
> back to place A --> All textures are being loaded again... Slowly.

Are you sure?  I thought so for a while, but that's not the case.  If
it is a busy place there are probably some new avatars with new
textures to load.  I think the caching could be imporved, but it is
there, and it is working.  Just don't confuse downloading textures
from the network with retrieving them from disk and redecoding the
jpeg2000 images.  Decoding does take time, and unless you look at the
network traffic for textures, and there is a display Control-Shift-1,
you might not know the difference.

> Why is it that? Doesn't anyone care about performance?

You should have seen OpenJPEG before my patch.  That's called
unusable.

-- 
David Fries <david at fries.net>
http://fries.net/~david/ (PGP encryption key available)