search

shana / google-highly-open-participation-mono

Automatically exported from code.google.com/p/google-highly-open-participation-mono
0 stars 0 forks source link

Improve Performance or Reduce Memory Usage in the Mono Compiler. #64

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is a continuation of Issue #4

In the Mono C# compiler, performance is tightly bound to memory usage.  
The less memory we use, the faster the compiler is.

The goal of this task is to reduce the memory usage used by the Mono C#
compiler.   A previous high-school student helped accelerate the Mono C#
compiler and eventually went to work for Google for the summers.

But as time has passed, the compiler has become chubbier and it could use a
number of passes to reduce its memory usage again (the last time we looked
at performance on it, it was two years ago).

The goal would be to reduce the memory consumption by 10% on bootstrapping
itself or in compiling any of the Mono libraires (mscolibr, System).

This task should take anywhere between 5 and 10 days.

The fix should not break the compiler, so all the tests should continue to run.

For additional information, see:
http://code.google.com/p/google-highly-open-participation-mono/issues/detail?id=
4

Original issue reported on code.google.com by miguel.d...@gmail.com on 27 Dec 2007 at 9:32

GoogleCodeExporter commented 9 years ago 
For the record, one thing that is useful is to use HeapShot to profile 
applications,
more docs can be found here:

http://www.mono-project.com/HeapShot

You might want to add a ReadLine() before the compiler finishes to give you a 
chance
to snapshot memory usage.

Original comment by miguel.d...@gmail.com on 27 Dec 2007 at 9:33

GoogleCodeExporter commented 9 years ago

Original comment by jpo...@gmail.com on 27 Dec 2007 at 11:28

GoogleCodeExporter commented 9 years ago 
I claim this task.

Original comment by andreas....@gmail.com on 31 Dec 2007 at 1:13

GoogleCodeExporter commented 9 years ago

Original comment by jpo...@gmail.com on 31 Dec 2007 at 4:18

GoogleCodeExporter commented 9 years ago 
Hello,

this are my first results after a few days of profiling and optimizing. Memory 
usage
for a compilation of corlib has been reduced by 7-8% ( performance gain is 
~5-6% ).
The results for mcs are worse though, only 2%. (SeekableStreamReader.patch is 
much
less effective here, since mcs consists of fewer source files. In addition a 
lot of
time is spend working with the large method(s) inside cs-parser.cs (600+ 
blocks!).
While it is possible to reduce memory usage here, I found that doing so hurts
performance badly...)

I am not sure if CombinedArrayList.patch is complete. A full compile worked and 
all
of the mcs tests passed, but I'm not sure if I found all the bits that use
member/method hash.

Andreas Noever

Changelog:

foreach.patch:
 * Changed some foreach loops to for loops in commonly used methods.

mcs:
Total memory allocated: 59199 KB -> 58889 KB
corlib:
Total memory allocated: 133604 KB -> 132766 KB

MemberCore.patch
* ArrayList defaults to a capacity of 16 elements. I have added a new 
constructor to
MemberCoreArrayList and some default capacities.

mcs:
Total memory allocated: 59199 KB -> 59137 KB
corlib:
Total memory allocated: 133604 KB -> 133480 KB

MemberList.patch
* Some optimizations to the MemberList type. (It seems that there is no way to
initialize an ArrayList with a capacity of 0.)

mcs:
Total memory allocated: 59199 KB -> 59191 KB
corlib:
Total memory allocated: 133604 KB -> 133601 KB

SeekableStreamReader.patch:
* SeekableStreamReader allocates 3KB of memory each time it is created. Since 
only
one Reader is used at a time there is no need for each instance to allocate a 
new
buffer. This saves 3KB per input file. (Note: I have added a fallback that 
reverts to
the old behaviour, if more than one active instance of SeekableStreamReader is
detected. This is not required for mcs to run correctly and can be removed.)

mcs:
Total memory allocated: 59199 KB -> 58947 KB
corlib:
Total memory allocated: 133604 KB -> 124887 KB

CombinedArrayList.patch:
* Membercache deep copies the member_hash of it's base. Instead of copying the
ArrayLists this patch uses a new MemberCache.CombinedArrayList to transperantly
combine the old List with a new ArrayList (only created if new entries are 
added).

mcs:
Total memory allocated: 59199 KB -> 58400 KB
corlib:
Total memory allocated: 133604 KB -> 132816 KB

All:
mcs:
Total memory allocated: 59199 KB -> 57767 KB (2.4%)
corlib:
Total memory allocated: 133604 KB -> 123134 KB (7.8%)

Original comment by andreas....@gmail.com on 3 Jan 2008 at 2:43

Attachments:

GoogleCodeExporter commented 9 years ago 
Two more patches. Memory usage for corlib has been reduced by 8.6% (including 
the
previous patches).

Changelog:

foreach_csparser.patch:
 * Changed two foreach loops in cs-parser.jay ( declare_local_variables ). ( Note:
this is in addition to the first foreach patch)

mcs:
Total memory allocated: 59199 KB -> 59050 KB
corlib:
Total memory allocated: 133604 KB -> 133318 KB

globalOps.patch:
 * Convert::GetConversionOperator needs one temporary ArrayLists per invocation. The
list is now saved in a static variable for reuse.

mcs:
Total memory allocated: 59199 KB ->  58844 KB
corlib:
Total memory allocated: 133604 KB -> 132844 KB

All:
mcs:
Total memory allocated: 59199 KB -> 57284 KB (3.2%)
corlib:
Total memory allocated: 133604 KB -> 122091 KB (8.6%)

Original comment by andreas....@gmail.com on 5 Jan 2008 at 7:07

GoogleCodeExporter commented 9 years ago

Original comment by andreas....@gmail.com on 5 Jan 2008 at 7:07

Attachments:

GoogleCodeExporter commented 9 years ago 
This is great, done!

I will be integrating these patches soon.

Original comment by miguel.d...@gmail.com on 6 Jan 2008 at 8:20

GoogleCodeExporter commented 9 years ago 
I am not sure whether we should apply CombinedArrayList2.patch because 
MemberCache
needs major refactoring to work better with generics (currently it blocks only 1
feature) and it probably will change it's internal structure completely which 
this
patch will make harder to do.

Original comment by marek.safar@gmail.com on 7 Jan 2008 at 12:44

GoogleCodeExporter commented 9 years ago 
I agree.

Original comment by miguel.d...@gmail.com on 8 Jan 2008 at 12:10