Brendon Eich of Mozilla, claimed many times at TAE that FireFox 3 will have
the Tamarin engine in it (it's possible that the current alpha does not have
it in yet) and it will have about a 10X increase in speed. It is a JIT
compiler for JavaScript developed by Adobe. I have also read other articles
on Tamarin, some claiming as much as 100X increase in speed.
Jim
On 8/4/07, Sebastian Werner <[EMAIL PROTECTED]> wrote:
>
> Hi Jim.
>
> Do you mean that Firefox3 is 10% or 10X faster? Just curious. For me
> Firefox 3 is comparable in speed to Firefox 2. Nothing to beat Webkit for
> now.
>
> Sebastian
>
>
>
>
> Am 04.08.2007 um 20:38 schrieb Jim Hunter:
>
> Good luck. I have found it hard to fight others that think web
> applications should have the exact same speed as native desktop apps. They
> currently are slower, and there is nothing you can do about that. There are
> limitations in what JavaScript in a browser can do and how fast it can be
> done. FireFox 3 promises about a 10X increase in JavaScript speed but that
> is still some time off.
>
> If you are using a remote modal and you are seeing delays making a single
> row scroll then there is something that you are doing wrong. You should only
> see a delay when you are fetching data. And if you don't have enough rows in
> your buffer to handle a single row scroll then you need to re-work your
> code. I don't use the remote modal but load many hundreds of rows and I can
> scroll up and down without delays. So if you have the data available it
> should scroll well. You have to remember also, that there is no rendering
> going on with a horizontal scroll, that data is already created. All you are
> doing is moving the clipping widow. With vertical scrolls, the row objects
> need to be created and added to the object matrix, so there will ALWAYS be a
> slight difference between horizontal and vertical scrolling.
>
> Good luck.
>
>
> On 8/4/07, Bart van der Werf <[EMAIL PROTECTED]> wrote:
> >
> > It is 300ms per scroll action, regardless if it is 1 row or a pagedown,
> > so if you are using a cursor to step down thorugh a table it is near
> > unworkable.
> > I agree that the bottleneck seems to be in te browser not javascript.
> >
> > well it should be near instantaneous, 600 cells isn't really that much
> > data at all.
> >
> > Horizontal scrolling in the grid is completely smooth, while vertical
> > scrolling isn't, while must users scroll vertically.
> > That kind of behaviour is causing me to get bad feedback from others.
> > is it possible to use native scrolling for say 50 lines, and doing a new
> > page after that ? ie maybe 100 rows in the html table, with native scrolling
> > through that until that is used up and a new html table is made with 100
> > rows.
> >
> > I believe i allready use a remote table model, any ways the bottle neck
> > is the innerhtml/dom manipulation.
> >
> > the table data is a join from several dozen tables, atleast in the
> > database it is normalized :)
> >
> > The problem is that it is basicly a port of the current desktop
> > application, so i can't change the way the application should work in major
> > ways.
> >
> > the feedback i'm getting from higher up is that i need to show more rows
> > and columns, and that it needs to be faster to be acceptable as a product.
> >
> > I might be able to get a small bit of sponsoring if someone could
> > implement native scrolling for the vertical scrollbar for blocks of maybe
> > 100 rows.
> >
> > ________________________________
> >
> > Van: Jim Hunter [mailto: [EMAIL PROTECTED]
> > Verzonden: za 4-8-2007 9:57
> > Aan: qooxdoo Development
> > Onderwerp: Re: [qooxdoo-devel] qx.ui.table.Table with (too) many columns
> >
> >
> > 300 ms to do a page down (20 columns x 30 rows = 600 cells, is a full
> > page not a row scroll) is not that slow. Are you thinking that displaying
> > that much data should be instantaneous? That's not going to happen with any
> > of the toolkits. I have evaluated them all and this is one of the fastest
> > grids out there. I would suggest that you take a look at the remote table
> > modal as it might fit your needs a little better. Plus, reduce the number of
> > columns! If they 'have to see all that data' then I suggest creating views
> > of related data (it sounds like you are doing this since you are now only
> > showing 20 columns) and putting the views in separate grids. Also, if all
> > your data is in a table that has 120 columns, I would seriously suggest
> > doing some normalization on your tables as 120 columns is extremely high for
> > a normalized table.
> >
> > Also, if you reduce the number of rows showinf on the screen at one time
> > I bet you will get more speed out of the scrolling.
> >
> > Jim
> > www.D4PHP.org < http://www.d4php.org/>
> > www.D4PHP-Hosting.com <http://www.d4php-hosting.com/>
> >
> >
> >
> > On 8/2/07, Bart van der Werf < [EMAIL PROTECTED]> wrote:
> >
> > only short strings all data is formatted on the serverside
> >
> > the base data has about 120 columns, but we're bringing it down
> > to 10-20 ish, but this still makes qx sluggish
> >
> > about 20000 rows, but we're using blocks so only about 200 rows
> > are actually on the browser at anytime.
> >
> > on my screen i visually see about 30 rows, and 7 columns.
> >
> > this means that for every single row scroll it rerenders about
> > 600 cells for a 20column table.which takes about 300ms
> >
> >
> > ________________________________
> >
> > From: Jim Hunter [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 01, 2007 6:27 PM
> > To: qooxdoo Development
> > Subject: Re: [qooxdoo-devel] qx.ui.table.Table with
> > (too) many columns
> >
> >
> >
> > long amounts of code does not equate to more time. CSS
> > Style Sheets are slower to process then inline code is. You never did let us
> > know what your idea of a large grid is. How many rows? How many columns?
> > What sort of data is in the grid, numbers, short strings, very long strings?
> > Images? There could be many reasons you are seeing a slow down, we need to
> > get to the root of the problem.
> >
> > Jim
> > www.D4PHP.org <http://www.d4php.org/>
> > www.D4PHP-Hosting.com <http://www.d4php-hosting.com/>
> >
> >
> >
> > On 8/1/07, Bart van der Werf <[EMAIL PROTECTED]> wrote:
> >
> > I've been looking at what qx generates.
> >
> > the following was the element for a single
> > gridcell
> >
> > """
> > <div
> > style="position:absolute;left:100px;top:0px;width:100px;height:15px;overflow:hidden;white-space:nowrap;border-right:1px
> > solid #eeeeee;border-bottom:1px solid
> > #eeeeee;padding-left:2px;padding-right:2px;cursor:default;-moz-user-select:none;">5</div>
> >
> > """
> >
> > Does it really need to be this big?
> > Would it be faster if i would creates css styles
> > with a shortname and use those for the common cases instead of this long
> > sequence for every cell ?
> >
> > greets, Bart
> >
> >
> > ________________________________
> >
> > From: Bart van der Werf [mailto:
> > [EMAIL PROTECTED]
> > Sent: Wednesday, August 01, 2007 10:10
> > AM
> > To: qooxdoo Development
> > Subject: [qooxdoo-devel]
> > qx.ui.table.Table with (too) many columns
> >
> >
> >
> > I'm having some performance issues,
> >
> > We are using a very large grid and the
> > number of columns is causing qx to become very slow.
> >
> > At the top of the profiling results of
> > venkman profiler are:
> >
> > 72000ms
> > qx.ui.table.cellrenderer.DefaultupdateDataCellElement
> >
> > : function(cellInfo, cellElement)
> > 22000ms
> > qx.ui.table.pane.Pane_updateContent_orig
> >
> > : function(completeUpdate, onlyRow,
> > onlySelectionOrFocusChanged)
> >
> > No other function comes above 5000 ms.
> >
> > Is it possible to have the same block
> > like behaviour for columns as allready is supported for rows ?
> >
> > greets, Bart
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find
> > problems? Stop.
> > Now Search log events and configuration files
> > using AJAX and a browser.
> > Download your FREE copy of Splunk now >>
> > http://get.splunk.com/
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> >
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
> >
> >
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>
> http://get.splunk.com/_______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
