RE: [mylar-dev] this week's plan (v0.3.9)

["Mik Kersten" <beatmik@xxxxxxx>]

Eugene,

 

No, not submitting user monitoring should not slow anything down, just bloat the log file on your drive and make it slower to upload.

 

Good point on the accessibility, the actions are now in the drop-down.  Also, you’ve convinced me that the multiple checkboxes are too weird, and it should be obvious from the labels that a further out degree includes an earlier degree.  So this will be fixed soon (report is https://bugs.eclipse.org/bugs/show_bug.cgi?id=110464).

 

Also, you’re right that limiting search results is not consistent with the rest of Eclipse, which is happy to churn for 20 minutes trying to create a large type hierarchy.  And we’re running the searches via the same mechanism (just with way lower priority) so they can be terminated, etc.  How is the performance of switching degree on the latest build (v0.3.8.4)?  From my understanding a failure of Eclipse to repaint is not Eclipse, but the VM swapping in paged out stuff, GC’ing, or trying to allocate more memory.  Perhaps a broad search could trigger this when attempting to load resources, and I wouldn’t notice because with Mylar my Eclipse almost never gets over 120MB and I have tons of free RAM so Windows doesn’t page out.  Perhaps another issue could be an interaction AJDT, which we me and the other AspectJ devs run with 3-4 times the 256MB that you have in your –Xmx.

 

Mik

 

---

From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
Sent: September 20, 2005 8:04 PM
To: Mylar developer discussions
Subject: Re: [mylar-dev] this week's plan (v0.3.9)

 

Mik Kersten wrote:

  Strange, but it seems that it behave much better now.
  Could it be because I wasn't submitting user study monitoring results for several weeks? Just did that this morning...

   Hmm. I believe that using multiple check boxes is really confusing.

The way you've described it is just a single choice and it would be more

intuitive to use something like "radio button" idems similar to .

I agree the multiple check boxes are weird, but how else do we indicate that

when you have it set to "3: project", it *also* runs the searches for "1:

landmarks" and "2: interesting files"?  There are fancier widgets that would

work better for this, but for the time being we need something simple.

  To me these 0..5 numbers already intuitive enough and single checkbox/radio would be more sufficient...

  Actually I wonder what kind of widget you have in mind? Please don't use sliders.

  By the way, it would be nice for accessibility to have the same drop-down menus available from a view menu for active search.

   Not much difference between 0 and 1, 2 freezes for 20 seconds and 3 -

for few minutes. None of views are updated in that time.

   Actually the most noticeable freeze happens when I change degree

level or add something to the landmark (especially when resource is

referenced a lot). After that initial freeze the active search view

seems working ok with degree 2.

   It also seems that there should be a limit on the size of search

result in case when something is referenced a lot.

Good idea, I've scheduled it for this week:

https://bugs.eclipse.org/bugs/show_bug.cgi?id0042

  Interestingly, but neither standard search or quick-type popup (from Ctrl-T) allows to limit results and can cause similar freeze effect (e.g. try to use Ctrl-T on Object.toString() method)

But I'm still concerned about the freeze that you're seeing.  I have 75

source projects in my workspace, and if I switch between degrees there is no

noticeable delay.  The initial switches to high degrees take a couple

seconds or so to populate the view, until the results are cached at which

point it's faster.  I realize that we don't yet have reproducible steps, but

could you report this as a bug where we can diagnose it?  Please include the

following:

- description of the freeze (e.g. does Eclipse's titlebar go white), does

anything populate the Progress view before the freeze

  Toolbar is going white, CPU load is 100% and Eclipse is not repainting widgets (actually completely weird in this case because it is not entirely gray but rather partial loss of repainting)

- any messages that pop up in the PDE Runtime -> Error Log view

  Nothing in there and not in error log.

- Eclipse, OS, and VM versions 

  3.2M1
  win2000 sp2  1Gb RAM
 
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
  Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode, sharing)

- if you have the memory profiling visible on a note on how much is

allocated before and after the freeze

(http://www.eclipsezone.com/java/forums/t44200.html)

  That reminds me to update my patch for Eclipse 3.2... See http://jroller.com/page/eu?entry=eclipse_patches

  I've played with VisualGC and noticed heavy GC when changing degree. It seems that I should increase Eden space to reduce GC intervals.
  So, default settings from eclipse.ini are not good at all
-vmargs -Xms40m -Xmx256m
  It seems that increasing eden space additionally helped with performance...

  regards,
  Eugene