[Mono-list] mcs compiles on linux. Now what?

[Miguel de Icaza]

> 45-50 % of the time is spent parsing, now. miguel mentioned he had a few
> ideas about ways to speed-up the parser, maybe when he wakes up
> he can elaborate. Loading the file in memory at once is sure worth,
> but this should probably be implemented at the IO.FileStream level.

We need to run mcs with --timestamps in both Linux and Windows.   The
first time stamp shown is the parsing time.  In my Windows machine, this
is the output:

quack$ time ./mcs --timestamp --target exe --unsafe -o mcs2.exe
assign.cs attribute.cs driver.cs cs-parser.cs cs-tokenizer.cs tree.cs
location.cs cfold.cs class.cs codegen.cs const.cs constant.cs decl.cs
delegate.cs enum.cs ecore.cs expression.cs genericparser.cs interface.cs
literal.cs modifiers.cs namespace.cs parameter.cs report.cs
rootcontext.cs statement.cs statementCollection.cs support.cs
typemanager.cs
[01:381] Loading references
[00:070]    References loaded
[00:010] Initializing Core Types
[00:010]    Core Types done
[00:000] Resolving tree
[00:050] Populate tree
[02:733] Emitting code
[14:340]    done
[00:000] Closing types
[00:250] Saved output

real	0m21.977s
user	0m0.010s
sys	0m0.010s

So 1/15h of the time is spent on parsing on Windows.  If we are getting
different numbers on Linux, we should not look into optimizing the
parser and the tokenizer, but optimizing the underlying functions.

The tokenizer alone on Windows consumes 0.651 seconds on the compiler
sources:


quack$ time ./mcs --tokenize *.cs 
...
real	0m0.651s
user	0m0.030s
sys	0m0.000s

Ie, 1/33th of the time is spent on the tokenizer, not really a good
place to optimize.

> 15 % is spent in String.BoyerMoore: a dumb search is sure faster than
> initializing a 65536 element skiptable :-)

Heh, is this initialized for every string?  Oh my

Miguel