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/ _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
