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
|