Re: [p2-dev] Review wanted. Simplifying the IQueryResult/IQuery API

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

This is just from intuition, deja vu and my current experience with the competition data set where we handle 30 000 IUs (more on the competition during next week call). We don't have actual perf tests for this, though running the Planner tests should give you an idea since it contains a few test cases from very large instances.
The places that come to mind are:
AttachmentHelper
OperationGenerator
SimplePlanner

and more generally any place where we end up creating a collection with an initial size.

Also, why do you want to remove collection but not removed toArray?

And finally, in case of lazy repos, how do you see progress monitoring and exception (e.g. lost connection while going through the results) be done? But maybe this is a separate discussion.


Thomas Hallgren ---17/12/2009 06:32:59 PM---On 2009-12-17 18:26, Pascal Rapicault wrote:

From:	Thomas Hallgren <thomas@xxxxxxx>
To:	p2-dev@xxxxxxxxxxx
Date:	17/12/2009 06:32 PM
Subject:	Re: [p2-dev] Review wanted. Simplifying the IQueryResult/IQuery API

---

On 2009-12-17 18:26, Pascal Rapicault wrote:
>
> I have not reviewed the patch but I'm not a big fan of the removal of 
> size and toCollection.
> They end up being particularly useful in some places, especially to 
> convert from one type to the other, or eventually create collections 
> with the right size up front (which saves a lot of growth when you 
> work on very large collections).
>
> I agree that there are cases where all the IUs can't be held in 
> memory, however there are cases in today's code (engine and planner) 
> where I don't see how not having all the IUs in memory is possible, 
> and where the presence of such methods is necessary.
> In the end I think I could probably leave without the toCollection, 
> but loosing size would likely cause performance issues.
>
I doubt that. I think it's rather the opposite given the number of 
unnecessary collection copies that were removed.

Is there any way we can compare performance, with and without my patch? 
Any particular scenarios that you are worried about?

- thomas

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev