Bugzilla – Full Text Bug Listing
| Summary: | LoadRevisionIndication should stream the revision | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Simon Mc Duff <smcduff> |
| Component: | cdo.core | Assignee: | Project Inbox <emf.cdo-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | stepper |
| Version: | 4.1 | Keywords: | helpwanted |
| Target Milestone: | --- | Flags: | stepper:
galileo-
|
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | Lighter, Faster and Better | ||
|
Description
Simon Mc Duff
Why do you expect higher efficiency? The list itself should not be a problem. Do you expect revisions to be purgeable from cache earlier with your proposed change? Can you provide a patch that illustrates it? BTW. I don't like to expose any Net4j details to the world ouside of the signals. This is for example the IChannel. The ExtendedDataIOStreams are the only exception that comes to my mind... (In reply to comment #1) > Why do you expect higher efficiency? > The list itself should not be a problem. > Do you expect revisions to be purgeable from cache earlier with your proposed > change? By streaming it will bring two things : - More efficient When the server will calculate the graph....it will send revision as soon he as one. The consumer... instead of doing nothing...will be able to merge the revision in his space at the same time. - Less Out of memory problem By adding CDORevision into a list... we cannot garbage collect them. In the case where we ask for a lot of objects... it whould not bring us into that mode. If we send the objects immediately, we will note go in that mode. > Can you provide a patch that illustrates it? I will do tonight. > BTW. I don't like to expose any Net4j details to the world ouside of the > signals. > This is for example the IChannel. The ExtendedDataIOStreams are the only > exception > that comes to my mind... (In reply to comment #2) > - More efficient > When the server will calculate the graph....it will send revision as soon he as > one. The consumer... instead of doing nothing...will be able to merge the > revision in his space at the same time. Yes, this was one of the very initial design requirements for Net4j, so I'm very willing to profit from it wherever possible ;-) > - Less Out of memory problem > By adding CDORevision into a list... we cannot garbage collect them. In the > case where we ask for a lot of objects... it whould not bring us into that > mode. I suspected this was your motivation and I can fully agree. Cool if you had the time to make a proposal, otherwise please ping me so that I have a look at it... Reversioned due to graduation Rebasing all unresolved enhancement requests to 3.0 Rebasing all outstanding enhancements requests to version 4.0 Moving all open enhancement requests to 4.1 No interest for years. WONTFIX. Closing. |