Bug 98566 - List.setItems() as slow as doing List.add() on GTK
Summary: List.setItems() as slow as doing List.add() on GTK
Status: RESOLVED INVALID
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.1   Edit
Hardware: PC Linux-GTK
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Billy Biggs CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2005-06-06 14:30 EDT by Tod Creasey CLA
Modified: 2005-06-08 10:49 EDT (History)
2 users (show)

See Also:


Attachments
SWT only List population test class from our suites (3.02 KB, text/plain)
2005-06-06 14:31 EDT, Tod Creasey CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tod Creasey CLA 2005-06-06 14:30:27 EDT
RC1
RH Enterprise 3.0

I am going to attacha test where we populate a list 2 ways

1) By adding 50000 items one at a time
2) By adding 50000 items all at once

On Windows the second method is about 4 times faster than the first. On GTK they
are about the same amount of time. This influences our ListViewer as we switched
from the first way to the second in 3.1 and have good performance improvements
on Windows and a performance degradation on GTK as a result
Comment 1 Tod Creasey CLA 2005-06-06 14:31:31 EDT
Created attachment 22444 [details]
SWT only List population test class from our suites
Comment 2 Tod Creasey CLA 2005-06-06 14:32:51 EDT
Here are the GTK numbers

Scenario
'org.eclipse.jface.tests.performance.ListPopulationTest#testMediumAdd()'
(average over 3 samples):
  System Time: 1.53 s
  Used Java Heap: -40674
  Working Set: 93.33K
  Elapsed Process: 1.53 s
  Kernel time: 0 ms
  CPU Time: 1.51 s
  Hard Page Faults: 1
  Soft Page Faults: 1
  Text Size: 0
  Data Size: 93.33K
  Library Size: 0


Scenario
'org.eclipse.jface.tests.performance.ListPopulationTest#testMediumSetItems()'
(average over 3 samples):
  System Time: 1.5 s
  Used Java Heap: -39677
  Working Set: 228K
  Elapsed Process: 1.5 stestMediumSetItems: tearDown...

  Kernel time: 0 ms
  CPU Time: 1.47 s
  Hard Page Faults: 0
  Soft Page Faults: 40
  Text Size: 0
  Data Size: 133.33K
  Library Size: 94.67K



Scenario 'org.eclipse.jface.tests.performance.ListPopulationTest#testLargeAdd()'
(average over 3 samples):
  System Time: 15.01 s
  Used Java Heap: 444.38K
  Working Set: 1.2M
  Elapsed Process: 15.01 s
  Kernel time: 3 ms
  CPU Time: 14.97 s
  Hard Page Faults: 0
  Soft Page Faults: 297
  Text Size: 0
  Data Size: 66.67K
  Library Size: 1.14M


Scenario
'org.eclipse.jface.tests.performance.ListPopulationTest#testLargeSetItems()'
(average over 3 samples):
  System Time: 14.96 s
  Used Java Heap: -63669
  Working Set: 1.12M
  Elapsed Process: 14.96 s
  Kernel time: 3 ms
  CPU Time: 14.9 s
  Hard Page Faults: 0
  Soft Page Faults: 301
  Text Size: 0
  Data Size: 42.67K
  Library Size: 1.08M

Comment 3 Tod Creasey CLA 2005-06-06 14:34:52 EDT
Here are the XP numbers

Scenario
'org.eclipse.jface.tests.performance.ListPopulationTest#testMediumAdd()'
(average over 100 samples):
  Used Java Heap: 4.94K
  Working Set: 200.92K
  Committed: 201.48K
  Working Set Peak: 4.52K
  Elapsed Process: 37 ms
  Kernel time: 1 ms
  Page Faults: 156
  CPU Time: 37 ms
GDI Objects: 0


Scenario
'org.eclipse.jface.tests.performance.ListPopulationTest#testMediumSetItems()'
(average over 100 samples):
  Used Java Heap: -908
  Working Set: -27525
  Committed: -11059
  Working Set Peak: 3.36K
  Elapsed Process: 13 ms
  Kernel time: 1 ms
  Page Faults: 41
  CPU Time: 13 ms
  GDI Objects: 0

Scenario 'org.eclipse.jface.tests.performance.ListPopulationTest#testLargeAdd()'
(average over 4 samples):
  Used Java Heap: 89.09K
  Working Set: 9.53M
testLargeSetItems: setUp...
  Committed: 9.33M
  Working Set Peak: 5.69M
  Elapsed Process: 1.19 s
  Kernel time: 324 ms
  Page Faults: 52.07K
  CPU Time: 1.18 s
  GDI Objects: 0

Scenario
'org.eclipse.jface.tests.performance.ListPopulationTest#testLargeSetItems()'
(average over 45 samples):
  Used Java Heap: 2.48K
  Working Set: 1.53M
  Committed: 1.52M
  Working Set Peak: 0
  Elapsed Process: 88 ms
  Kernel time: 4 ms
  Page Faults: 401
  CPU Time: 88 ms
  GDI Objects: 0

Comment 4 Billy Biggs CLA 2005-06-06 14:56:12 EDT
How is this a performance degradation?  It looks like they take the same amount
of time on GTK+.
Comment 5 Tod Creasey CLA 2005-06-06 15:01:28 EDT
Right but on Windows setItems() is much faster. We made a change for Bug 70856
to switch to setItems. This gave us some really good improvments on Windows but
ended up causing a slowdown on GTK.
Comment 6 Billy Biggs CLA 2005-06-06 15:14:45 EDT
The slowdown is not demonstrated by your test application here.  Is there a case
which is slower?

I have some theories about why add() would be significantly slower than
setItems() on Windows, for example, work is done on every call to add() to fix
the horizontal scrollbar but is only done once in a call to setItems().  This
does not apply in GtkTreeView.

There is no reason why setItems() should be slower, but it shouldn't be faster
either.  I am not sure there is any bug here.
Comment 7 Steve Northover CLA 2005-06-06 16:47:09 EDT
I'm not sure there's a bug here either.  There is no guarantee that setItems() 
is faster than add() for the same number of items on every platform.  The main 
thing is that is cannot be slower.  BB to close.
Comment 8 Billy Biggs CLA 2005-06-08 10:49:25 EDT
Please re-open if you have a case where setItems() is slower than looping and
calling add().