Bug 272520 - [repository] Version optimizations in our Parsers and Writers
Summary: [repository] Version optimizations in our Parsers and Writers
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.6   Edit
Assignee: Thomas Hallgren CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2009-04-16 11:30 EDT by Simon Kaegi CLA
Modified: 2010-05-17 17:15 EDT (History)
3 users (show)

See Also:


Attachments
Simple optimization (1.83 KB, patch)
2009-04-17 17:31 EDT, John Arthorne CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Kaegi CLA 2009-04-16 11:30:34 EDT
In our parsers we can use the Version/VersionRange factory methods instead of direcly using the constructors to reduce memory footprint. see bug 272386. John also suggests that we might directly optimize for null version/version ranges in our parsers as we have the appropriate context.

In our writers we're currently writing many zero versions and version ranges; we can omit writing versions/versionranges in these cases. The net result will reduce the file size and subsequently speed up parsing.
Comment 1 Thomas Hallgren CLA 2009-04-16 11:33:30 EDT
Do you want any help with this?
Comment 2 Simon Kaegi CLA 2009-04-16 11:40:39 EDT
Go for it.
Comment 3 Pascal Rapicault CLA 2009-04-16 21:29:42 EDT
The writer must not be changed for 3.5 because people will use 3.5 to generate sites to be consumed for 3.4 and the resulting site will be unusable with 3.4!
The only change I could  see happening for 3.5 are:
- use the factory method in the parser
- prepare the reader to deal with cases where we eventually don't have empty ranges

But I don't even see any of those change must fix / stop ship in the light of the rest of the work we have (e.g. improving the director application) and the risk / reward is unclear to me.
Unsetting milestone for now. Feel free to convince me otherwise.
Comment 4 John Arthorne CLA 2009-04-17 11:46:53 EDT
What we really need here are some concrete measurements. If we knew a particular change would save X KB/MB of memory for a particular scenario, that would help motivate whether the change is worthwhile. If I do some more performance work this afternoon I may try some simple optimizations to see what kind of improvement they yield.
Comment 5 John Arthorne CLA 2009-04-17 17:31:32 EDT
Created attachment 132307 [details]
Simple optimization
Comment 6 John Arthorne CLA 2009-04-17 17:36:22 EDT
This simple optimization helps quite a bit. I ran Bug254481dataSet1 with and without this optimization and found:

Before:

Version: 21,313 instances, 1,761,328 bytes
VersionRange: 7,333 instances, 1,222,648 bytes

After:

Version: 14,956 instances, 1,354,480 bytes
VersionRange: 5,811 instances, 1,076,526 bytes

Overall the memory retained by the Profile instance decreased by 445,280 bytes. I think this is a worthwhile optimization so I released it to HEAD.
Comment 7 Thomas Hallgren CLA 2009-05-06 02:53:03 EDT
John, do we want more optimizations in for 3.5 or should this be moved to 3.6?
Comment 8 Pascal Rapicault CLA 2010-05-17 17:15:53 EDT
Closing for now, since we don't intend to do anything.