[Mono-dev] VBNC uses too much CPU and RAM on Mono
Rolf Bjarne Kvinge
rolflists at ya.com
Wed Nov 1 06:11:35 EST 2006
>>> > > 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
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
- 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.
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the Mono-devel-list