Re: [platform-swt-dev] Large Tables

[Thomas Fletcher <thomasf@xxxxxxx>]

I don't have any good comments other than I would really like to see
better large data management in the widgets.  I have tried myself to
decouple the table from the scrollbar (ie setting a max/min and then
"filling on demand") but it was non-trivial and I was never satisfied
with the result (I was also trying to do it within the JFace content
provider framework).  

My final solution was to use the table as a viewport (so the min/max 
only scrolls the events in the table) and then to re-load the table 
based on user interaction (ie an up/down key event at the top/bottom 
of the table advances the index and extracts more data).  This is better
than nothing (or waiting for a _long_long_ time), but still doesn't 
"feel" right.  

I'm willing to help/try out anything that people want to propose/test
and give feedback.

Thomas

On Tue, 22 Oct 2002, Matthew Golby-Kirk wrote:

> Hi All,
> 
> I am writing a standalone SWT app on Windows, and require a table that 
> holds a 
> large number of rows (possibly as many as one million) with 10 columns.
> 
> Now using the Table / TableItem classes, the time taken to initialize the 
> table
> with all the data in one go takes too long, when the number of rows 
> exceeds
> about 15,000 on my machine (1.8Ghz P4, 1GB RAM WinXP), and when I exceed 
> 160,000
> entries it took over 2.5 hours to draw the table.
> 
> I have had two ideas as to ways to combat this, but both have problems, 
> and I would
> like opinions on how others may have solved this problem.
> 
> 
> Idea 1: Write a viewport class that only shows the first 100 rows, then 
> hook the vertical 
> scroll bar with a listener , reset the maximum entries in the scroll bar 
> and redraw the 
> data in the table on each scroll event.
> 
> Now I have written the class ok, but cannot seem to hook all the events 
> correctly,
> as the table appears to reset the scroll bar's size and selection without 
> sending an event,
> so my viewport scrollbar's thumb seems to go from being small to large
> without my being able to control it properly.
> 
> Idea 2: Subclass Table (which I know is not a good idea but I wanted to 
> see if I could 
> at least make things better) with a new LargeTable class and try to 
> improve the speed 
> at which things occur in the parent table by overriding methods.
> 
> Doing this I have improved the speed of showing 160,000 entries from 2.5 
> hours to 15 minutes
> simply by adding a setNumberItems(int size) method that resized the items 
> vector in one go, 
> rather that incrementing the items vector by 4 each time as the standard 
> Table code does. 
> However this is still too slow really.
> 
> Has anyone got any better ideas, and which is the best way to go forward 
> from here?
> 
> I have sample code I can post if it would help explain what I an trying to 
> do in each idea...
> 
> 
> Kind Regards,
> 
> 
> MGK
> 
> -
> Matthew Golby-Kirk   MQSeries Integrator Development
> Hursley Park MP 211  IBM UK Internal 24-6700
> Internet:: mgk@xxxxxxxxxx, Notes: Matthew Golby-Kirk/UK/IBM
> Phone: +44-(0)-1962-816700 Fax: +44-(0)-1962-816898
> http://muppet.hursey.ibm.com
> "Skating away, on the thin ice of a new day..."
> 

-------------------------------------------------------------
Thomas (toe-mah) Fletcher       QNX Software Systems
thomasf@xxxxxxx                 OS Technology Developer
(613)-591-0931                  http://www.qnx.com/