-
July 4th, 2009, 03:35 AM
#1
Large data
Sorry my english is not very well but i hope find the answer there.
I'm running LS to push data for a live stock quotes table. My table have 165 rows and 24 cols each row. It takes long time to display in ff3 and crash in ie6
Can anyone please advise?
Thanks.
-
July 6th, 2009, 10:26 AM
#2
Hi,
There could be several reasons why a table is slow to load. For example, your Data Adapter could be slow in producing the initial snapshot. Or your client PC could be too slow to process such a huge table without implementing some optimization (grid-style scroll, pagination, etc.). Or you could have some explicit or implicit bandwidth constraints.
I suggest you starting with a smaller table, while monitoring the system resources (especially on the client side).
-
September 3rd, 2009, 05:30 PM
#3
IE7-8 very slow
I have a similar problem
My page displays 19 columns (14 uses push technology) per 30 rows.
Data is taken from a stock exchange stream.
The very problem consists in a large time to get updates from LS.
E.G. the first time I load a list or every time I click on a column header for sorting.
On IE7/8 I got 50% CPU on iexplore.exe and the browser completely locked.
On FF 352 I have no problem at all and the CPU consumption is decently low (max 10%)
On Chrome 2.0.172 and on Safari 4 I’ve got stellar performances.
So it seems to be dependent from the JS interpreter running on the host browser.
The same behaviour can be reproduced using your samples.
The problem is that I must support IE7/8 and on these platforms my application cannot be delivered with push mode enabled; in polling mode the application is really faster and usable.
Have you got any clues about it?
-
September 4th, 2009, 09:02 AM
#4
It could depend on the custom JS code that is executed in the callbacks. We haven't seen any performance issue on IE with our samples (only the optional fading effect is heavy, but not blocking). Can you please explain us how to reproduce the problem?
In any case, there is a heuristic mechanism in our client library, so that if the code detects that the browser is not able to keep the pace of the inbound updates, it automatically switch to smart polling, in order to find the right pace. In this case, the server-side throttling, conflation, and batching algorithm will take place, in order to provide the best user's experience given the supported client-side frequency.
Similar Threads
-
By Cerogil in forum Client SDKs
Replies: 3
Last Post: September 27th, 2011, 08:56 AM
-
By jonasby in forum Client SDKs
Replies: 2
Last Post: June 17th, 2011, 09:21 AM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 05:38 PM.
Bookmarks