Summary: | [compiler] optimization: the distribution of the number of elements into CharArrayCache instances suggest that smaller instances should be optimized/removed | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Maxime Daniel <maxime_daniel> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | kent_johnson, philippe_mulet |
Version: | 3.2 | Keywords: | performance |
Target Milestone: | 3.2 M6 | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: |
Description
Maxime Daniel
2006-03-14 10:37:48 EST
We could also reuse the class file and remove the creation of byte[] just to dump the bytes. You could also consider having a classfile reader entry point allowing it to read from 2 byte[], this could speed incremental builder a little. Changing the classfile reader requires much more work since the class file reader is assuming that there is only one byte array to iterate. 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. 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 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. |