I can't see Guilherme Aiolfi's post in Nabble for some reason, but I did get it via the mailing list:
>Good work!!! I have one doubt though, from the wiki: The smart model uses >algorithms that scale well as the table size grows, and includes >optimizations specifically for huge tables. > >How huge are those tables? How many rows/columns are we talking about? The number of columns doesn't really have much bearing on the performance of this model. As for rows, in theoretical terms, if you add M rows to a table of size N, the code will generally sort the M rows in O(M lg M) time using the native sort routine and then merge these into the table in O(N) time. But there are a number of special cases: the code attempts to identify contiguous chunks of rows, for example, and insert using one native splice operation. Similarly, there is a threshold beyond which the code will just make an entirely new copy of the table rather than just splicing things in. Ultimately, I plan to add code to determine that threshold empirically at run-time, because it will vary by browser. What this means in practice, though, is hard to say, because it obviously depends on the JavaScript implementation and CPU in the end user's machine. IE6 is much, much slower than, say, Safari 4, so I would expect that you could have literally orders or magnitude more data in a table under Safari 4 than under IE6. But anecdotally, I have multi-thousand row tables with multiple views running fine in IE6 on a Core-class CPU running on a VM. Adding a single row is relatively more expensive than it was with the Simple model, but adding a big clump of rows is relatively cheaper. Your mileage may vary, but for most applications it should be more efficient to use the new model. For most applications where you would need to store the rows remotely, you will still want to do that -- if only to avoid consuming huge amounts of memory in your JavaScript process. Finally, if one were to create a huge number of views -- say, 100 -- then it would slow things down a lot. So I've thought about adding view properties, with which you could specify that a view should be sorted and filtered only when it's made visible. Right now all views are always kept sorted and filtered at all times. Dave -- View this message in context: http://www.nabble.com/Contrib%3A-new-%22smart%22-table-model-tp25530345p25530485.html Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
