[gclist] GC topics

[Darius Blasband]

> 
> Darius Blasband writes:
> 
>  > No. I have no figures on the cost in terms of storage of GC, but we have a 
>  > complete performance analysis on the current implementation of the YAFL
>  > programming language, and the results are interesting: if we remove all
>  > reference to GC from the generated code, the total execution time of
>  > the system drops to 70-80% of its original execution time (of course,
>  > this is only for analysis purposes, such a system is barely usable, since
>  > it just allocates memory and then crashes after a while...).
> 
> It seems to me that the situation is better for GC than it looks from
> the figures above: If you remove GC and run until you've memory you're
> getting the benefit of a quasi-zero cost allocator, but if you had a
> real system using malloc/free you would pay for them and the cost is
> not trascurable.
> 
> 				Maurizio Vitale

Agreed, but this was not entirely the issue. A customer who used YAFL
complained about the fact that a new system which was developed in YAFL
was much slower than the original version written in C.

Since these the two languages are pretty close in terms of performance
when it comes to microscopic code (arithmetics, array accesses, etc...)
we did look everywhere we could think of, and this is how we checked 
what was the performance overhead of our garbage collector.

Finally, it turned out that the major performance penalty came from new
functionalities which had been added to the application after being
redeveloped, using the higher level of abstraction of YAFL when compared 
with C.

Our figures were just a way of making sure that having a GC did not cost
use 50%+ of the execution time...

Darius