Hi all, Another Idea which may be interesting in case if customer does't agree to use pagination (our case). We had decided to generate table as static HTML on serverside (hello to JSP, JSF), in another word our custom component have server side html creator (or renderer in terms JSF). After generation the produced html is set as inner html to the custom widget and Bingo: table on 1000 records takes 3-4 seconds to be created.
Currently we are working on problem to insert action components (Links) in such type of tables and invoke appropriate functionallity with appropriate parameter when user clicks on such link. We digging into the JSNI here, and I suppose finally we succeed with this. So for teams where customer reject paging, this approach may be used I suppose. Offcource it looks strange and may be not elegant, but it is fast. 2009/2/27 federico <[email protected]> > > +1 for the custom hp solution > for the best performance at all i suggest a flow panel with inside > a list of flowPanels anc custom css styles > > On 27 Feb, 06:48, Tóth Imre <[email protected]> wrote: > > I have another solution for this problem.Into a Vertical panel inserted > > horisontal panel formatted it with css, and it is faster.. > > > > 2009/2/19 milind <[email protected]> > > > > > > > > > > > > > Hi Nick, > > > > > Flex table is pretty slow if you want to display 50+ rows in it at a > > > time based on our experience. The slowness also varies for each > > > browser, only realistic way of getting around this problem is to > > > implement pagination, where you display only 20-30 rows on each page > > > and then provide links on the header to navigate through the pages. > > > > > This way i am able to manage a display of thousands of records in less > > > than 500 milliseconds across the browsers (FF and chrome faster then > > > IE). > > > The application has many views with this approach displaying simple > > > tabluar data and also hierarchical data structures. > > > For displaying hierarchical data structures i initially went with > > > Tree, but that was pretty slow for large no. of rows, so i simulated > > > tree inside FlexTable using Click listener on (+/-) images. > > > This works like a charm. > > > > > Regards, > > > Milind > > > > > On Feb 18, 4:21 pm, Nick <[email protected]> wrote: > > > > Ok, Results > > > > What I’m finding is that the Grid does beat the FlexTable, but not by > > > > much with a small data set. Larger sets seem to widen the gap. My > > > > guess for this is that since FlexTable has the ability to add rows > > > > (Grid is sized from the start) that it works much like how other > > > > resizable constructs work such as Java’s ArrayList. My reasoning for > > > > this is that the first time the test is run the speed is very slow on > > > > the FlexTable (especially in IE). Repeated test runs after the > > > > initial are faster and I think this is because the table was being > > > > sized the first time as rows were added, and didn’t need to be > resized > > > > during the following tests. > > > > > > The other thing I’m finding is that performace varies based on > > > > browser. I’m seeing FF run reasonably well. With IE the Grid runs > > > > about the same as FF but the FlexTable runs considerably slower. I > > > > also tested Opera and was stunned as it blew both others out of the > > > > water. > > > > > > My full write up is here with times and a test application you can > run > > > > in your browser. > > >http://whatwouldnickdo.com/wordpress/401/performance-grid-vs-flextable/ > > > > > > On Feb 18, 2:10 pm, Nick <[email protected]> wrote: > > > > > > > Thanks for the response, I think you're correct. And it makes > sense > > > > > that adding rows dynamically would account for the increase in time > as > > > > > the row count is higher. > > > > > I'm going to run a few tests, and I'll post anything I find to this > > > > > post. > > > > > > > On Feb 18, 3:09 am, Alexey_Tsiunchik <[email protected]> > > > > > wrote: > > > > > > > > Hello Nick, > > > > > > > > Exactly the same issue was in our app. We need to display big > lists > > > > > > (100 - 500) records, and FlexTable seems not solution for this. > > > > > > > > The problem is that FlexTable always checks table bounds (row > number, > > > > > > column number) and when you put some value in FlexTable it > performs > > > > > > checking for bounds, moreover it not store the colnum and rownum > in > > > > > > some variables, but always calculate them dynamically. Moreover > it > > > > > > dynamocally adds new rows. > > > > > > Thats why it becomes slower when number of rows increase. > > > > > > > > We had decided to use Grid rather then FlexTable. We can specify > Grid > > > > > > bounds right after creation, and while we put data in cells in > the > > > > > > cycle its performance remains the same for different grid size > (here > > > I > > > > > > mean speed of adding row). > > > > > > > > But it also has it's disadvantages. When we need to display > another > > > > > > data in the same Grid, and this data has different number of > rows, > > > > > > we should call Grod.resize(int, int). And for > > > > > > big grids, this operation is very slow in IE (in our tests > resizing > > > > > > grid with 200 rows, 5 columns, takes ~13000 ms in IE). > > > > > > > > So It seems paging here the only solution. > > > > > > > > Tuesday, February 17, 2009, 6:40:51 PM, you wrote: > > > > > > > > > Ok, I did some more testing and I was wrong. It's not the > > > inserting > > > > > > > and removing from lists that are the bottleneck. I moved the > time > > > and > > > > > > > log statements around and it had to do with adding to the > FlexTable > > > > > > > itself. > > > > > > > I'm using code like: > > > > > > > int row = 1; > > > > > > > for (Iterator<MyData> iter = eventList.iterator(); > iter.hasNext(); > > > row+ > > > > > > > +) { > > > > > > > long sysTime = System.currentTimeMillis(); > > > > > > > int column = 0; > > > > > > > MyData event = (MyData)iter.next(); > > > > > > > table.setText(row, column, event.getNameLast()); > > > > > > > column++; > > > > > > > table.setText(row, column, event.getNameFirst()); > > > > > > > column++; > > > > > > > table.setText(row, column, event.getJob()); > > > > > > > column++; > > > > > > > GWT.log("update time 4: > > > "+(System.currentTimeMillis()-sysTime)+"ms > > > > > > > ", null); > > > > > > > } > > > > > > > Now, you can see I'm logging the time after every row is > inserted. > > > > > > > The odd thing I'm seeing is that the time per row increase as > rows > > > are > > > > > > > traversed. For example, row 1 takes about 30ms but as the rows > > > > > > > traverse by row 100 each row is taking about 150ms. It's a > steady > > > > > > > increase. > > > > > > > Any insights? > > > > > > > > -- > > > > > > Best regards, > > > > > > Alexey_Tsiunchik mailto: > > > [email protected] > > > > -- > > Best Regards > > Tóth Imre > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
