[Mono-dev] VBNC uses too much CPU and RAM on Mono

[Rolf Bjarne Kvinge]

Hello,

>>> > > Any help on speeding up vbnc is welcome.

First I'd like to apoligize for leaving this unanswered for so many days,  
the problem was that my motherboard went up in smoke and I had to get a  
new computer :(

> It seems that the linked list for *all* files was kept for the *entire*
> duration of the gc, from my profiling on windows. Rolf, can you confirm
> this?
The compiler is effectively keeing a linked list of all the tokens, and it  
keeps them until the compiler finishes (tokens are kept since they contain  
the source location for the token and would be necessary for any error  
messages.) I'm quite sure I can remove the entire list pretty easily  
though, so I'll try to fix this as soon as possible. However I don't think  
this is the real problem, after parsing the source the list is never  
walked, and then the only bottle-neck I can see would be the gc to take  
too long to walk the list in order to decide that it cannot be disposed  
of, but since Kornél's added gc collections and it worked better this does  
not really seem logical.

What I do know is that the compiler creates a huge number of temporary  
objects while compiling, and in my opinion this hurts the mono gc more  
(and this would match the fact that adding gc collections was making it  
better). Anyway, here are a few ideas of optimizations:
- I think some class is implementing a finalizer (don't remember which),  
this can be probably just be removed or commented out.
- Helper.ResolveGroup is called quite frequently and it creates a large  
number of temporary objects. I think this method should be changed, but it  
is one of the most complicated methods in the compiler, so it has to be  
done carefully. (I didn't profile this though).
- Helper.GetOverloadableSignatures creates a large number of strings (I  
profiled this), so this might be changed somehow.
- When a member lookup is done on a type, the compiler loads all the  
members of the type in question and all the ascendent types in order to  
create a flattened view of the type, and then the flattened type is  
cached. It might be better to load only the required member on the type  
and it's ascendent types and cache that. This is a somewhat bigger change  
though.
- When the scanner needs more source code, the entire source file is  
loaded into memory and the contents are scanned sequentially like an  
array. An idea might be to change it to be a more stream-like scanning of  
characters. I don´t know how much this will gain though, since the  
scanning part only takes a couple of seconds anyway.

I will also check if the vbruntime can be used as a better test case for  
performance than vbnc (it's smaller at least), and I think something more  
complicated than Hello World is necessary to profile performance.

Rolf
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/