Bug 131720 - [compiler] optimization: the distribution of the number of elements into CharArrayCache instances suggest that smaller instances should be optimized/removed
Summary: [compiler] optimization: the distribution of the number of elements into Char...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 enhancement (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2006-03-14 10:37 EST by Maxime Daniel CLA
Modified: 2006-04-18 06:51 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Daniel CLA 2006-03-14 10:37:48 EST
3.2 M5
I have run a measurement campain and got the following findings (by compiling a full source workspace plus a big library, using instrumented code):
- the vast majority of all instances will count at most one element;
- the following summary table gives a few tabs (for each percentage,
  the size given is such that taking the population of all sizes that
  are less than or equal yields the considered fraction of the total
  population - or more):
        default constructor     all constructors
99%     3                       62
98%     2                       33
95%     1                       7
90%     1                       2
87%     1                       1
- the experiment has been done with a total of almost 500K allocated objects;
- I have separated the default constructor case, which allocates a 13 slots 
  internal array, because my starting point for the investigation was the fact
  that lowering that number to 9 was making a favorable impact on perfs;
- it should be profitable to avoid useless creations; one element hash tables,
  even optimized ones, are expensive;
- anyway, over 8K instances are created that finally have no element (been
  empty all time, or emptied at some point in time); all these use a non
  default constructor, suggesting that there is little visibility in their use
  downstream; hence an optimized implementation for very small sizes is
  probably a must as well.

(I'll try to investigate a bit this week. Kent, Philippe suggested I copy you as well.)
Comment 1 Olivier Thomann CLA 2006-03-14 12:45:27 EST
We could also reuse the class file and remove the creation of byte[] just to dump the bytes.
Comment 2 Philipe Mulet CLA 2006-03-14 13:09:08 EST
You could also consider having a classfile reader entry point allowing it to read from 2 byte[], this could speed incremental builder a little.
Comment 3 Olivier Thomann CLA 2006-03-14 21:10:03 EST
Changing the classfile reader requires much more work since the class file reader is assuming that there is only one byte array to iterate.
Comment 4 Olivier Thomann CLA 2006-03-21 14:36:55 EST
This is fixed.
There is no more charArrayCache that are created with only one element. This covers 87% of the use cases.
Fixed and released in HEAD.
In order to verify this, ask Maxime how to set up the stats in charArrayCache.
Comment 5 Frederic Fusier CLA 2006-04-14 13:20:07 EDT
This bug is referenced in our buildnotes list but target was missing...
Maxime, please verify it on 3.2 M6 with your stats in charArrayCache and set as VERIFIED if everything is OK, thanks
Comment 6 Maxime Daniel CLA 2006-04-18 06:51:16 EDT
I ran new stats on M6, and the number max of elements distribution now looks like:
     default constructor   all constructors
99%  12                    68
98%  9                     45
95%  6                     24
90%  4                     8
71%  2                     3

Which means that the distribution has much improved (flattened), despite a remaining pick under 8.
Note also that a concurrent optimization has lowered the number of CharArrayCache-s needed (on the considered test case, a ten factor).

Verified for 3.2 M6 using build I20060331-2000.