Bugzilla – Full Text Bug Listing
| Summary: | [context] move task-specific editor memento storage out of the plug-in preference store | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> | ||||||||||||||||||||
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> | ||||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||||||
| Priority: | P2 | CC: | jtk499, manuel.doninger, mik.kersten, robert.munteanu, steffen.pingel, stepper, wim.jongman | ||||||||||||||||||||
| Version: | unspecified | Keywords: | plan | ||||||||||||||||||||
| Target Milestone: | 3.7 | ||||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||||
| OS: | Windows Vista | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| Bug Depends on: | 255923, 275899, 332697, 371984, 372432, 372553, 373186 | ||||||||||||||||||||||
| Bug Blocks: | |||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Mik Kersten
Also remove coupling to Tasks in ContextEditorManager. Also move ContextEditorManager to ..contex.ui. Not critical, deferring to 3.1. Proposed design: * Create an internal facility along the lines of ContextMementoManager. This should probably be in ..context.ui. * This will store a memento with all Workbench/UI state associated with the task. Currently that's the editor mementos and the active perspective. In the futrure it could also include editor splits (bug 171269). * Won't be API for now, since everything that needs it is internal in ..context.ui, but could be API later. * This hooks into AbstractContextListener, stores its state in the plug-in data location, not preferences, since we can get bloat with editor mementos. * Need to migrate state from: .metadata\.plugins\org.eclipse.core.runtime\.settings Created attachment 123033 [details]
patch in progress
Created attachment 123034 [details]
mylyn/context/zip
Created attachment 123040 [details]
updated patch
Created attachment 123142 [details]
next iteration
Created attachment 135417 [details]
updated with new context listener framework
I have updated this patch with the new context listener stuff and changes made to the ContextEditorManager.
Remaining work: * Test case * Delete preferences after migration * Ensure that lazy savings job completes before shutdown * Clean-up code Created attachment 152557 [details]
in progress
Created attachment 152558 [details]
mylyn/context/zip
As per discussion on conference call the mementos will be stored in workspace/.metadata/.mylyn/contexts/workspace Created attachment 153653 [details]
updated patch
Created attachment 154288 [details]
next iteration
Todo:
* Test case for editor mementos
* Test case for URL refactoring
* Test case for cloning contexts
Also need to consider saving the context memento on shutdown. We may not either need to deactivate the active task or persist the state independently. With regard to http://wiki.eclipse.org/Mylyn/FAQ#Why_does_startup_of_org.eclipse.mylyn.context.ui_take_so_long.3F I wonder what is "large" in this context. My file is about 2MByte -- is this large? What happens if I delete it -- is it restored or do I loose some information? (In reply to comment #17) > I wonder what is "large" in this context. > > My file is about 2MByte -- is this large? Mine was 16MByte :P If the preferences file is deleted editors will not be restored on task activation. I would not worry too much about it. I guess that there was something funny about the file in Eike's case that was causing loading to be much slower than normal. I would not expect reading of 2 MB of preferences from disk to take longer than a second. Moving to backlog. Bug 338554 needs to be completed first. I uploaded a review with proposed changes here: http://review.mylyn.org/#change,307. The changes have been pushed to master. The editor and perspective state is now stored under <workspace>/.metadata/.plugins/.mylyn/tasks/<repository>/data/<task id>/. Automatic conversion code runs on first task activation and copies the content from <workspace>/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.mylyn.resources.ui.prefs to the new location. The old information in the preferences store is not deleted, yet, but I will enable that as soon as we are confident the new mechanism works. Steffen, do you want to wrap this in a job, or maybe pop up a dialog that it's going to happen? While creating thousands of files here should be the exception, not the norm, I do wonder if for non-SSD machines we could end up with enough of a hang that people kill their Eclipse. (In reply to comment #23) > Steffen, do you want to wrap this in a job, or maybe pop up a dialog that it's > going to happen? While creating thousands of files here should be the > exception, not the norm, I do wonder if for non-SSD machines we could end up > with enough of a hang that people kill their Eclipse. We could consider that. It's a one time migration though and I would like to see an indication of problem before taking action. It took less than 10 sec. on my machine and I think it's rare that users will have a comparably large store but if you see any significant problems please let me know. I added a progress monitor since the migration can indeed take long enough to cause minor irritation. Steffen, moving this stuff onto disk should free memory and improve performance. How much would be the performance improvement here? I am asking because some people at my company always complaining about "bad performance" with Mylyn. Thanks, Jörg (In reply to comment #26) > Steffen, moving this stuff onto disk should free memory and improve performance. The memory saving depends on the size of the preference store which in turn depends on the number of editor mementos stored. If editor management is enabled a memento is stored for each task that is deactivated. On my system the store had accumulated 5 MB worth of editor mementos over the years. > How much would be the performance improvement here? I am asking because some > people > at my company always complaining about "bad performance" with Mylyn. In terms of performance the change should lower workbench startup time when the preference store was loaded into memory. It won't make a difference when working with the workbench. We have a number of open bugs tagged as [performance] in the summary. Please comment on the bugs if any of the descriptions match what your colleagues are experiencing so we can prioritize accordingly or please file new bugs if you are seeing specific performance problems. Steffen, every time I restart Eclipse, I am getting a progess dialog that says "Migrating context information" the first time I activate a task. That's intended. The original data is not yet deleted (see comment 22). I am getting the window "Migrating context information". I left it on all night but it does not go away. I forcefully ended my eclipse a few times but the window keeps popping up. There seems to be no disk activity. We have our own connector that needs to connect to the database before any of the tasks can be read. I can see our login window but it is blocked because the "Migrating" window is modal. Could that have some meaning? There is a Cancel button but that does nothing but grey out after pressing it. Steffen, it sounds like this could be a deadlock due to the migration waiting on the login prompt. Could we fix this just by making the dialog non-modal? |