Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010649Openbravo ERPI. Performancepublic2009-09-17 18:222009-10-01 00:00
Reportermondalaci 
Assigned Toshuehner 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOS5OS Version
Product Version2.50MP5 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0010649: Grid scrolling is slow
DescriptionScrolling in the grid is pretty damn slow.

It takes about 2 secs to select another record and about 5 secs to update when scrolling a whole page.

These measurements were done on powerful desktop computers. We've tried compiling JavaScript engines to mitigate the issue. Enabling TraceMonkey didn't do any speed improvements and Google Chrome didn't work with the grid.
Steps To ReproduceScrolling in any grid that has some content.
Proposed SolutionSince no AJAX requests are happening I assume that the grid updates its content from client-side data structures. If so, I guess the DOM code could be optimized for speed.
Additional Information
TagsNo tags attached.
Relationships
related to feature request 0010817 new iciordia Preload the attachment icon infos for all records 
related to feature request 0010818 new iciordia Changeable preload buffer size for grid windows 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-09-17 18:22mondalaciNew Issue
2009-09-17 18:22mondalaciAssigned To => rafaroda
2009-09-18 08:07rafarodaNote Added: 0020171
2009-09-18 08:07rafarodaAssigned Torafaroda => shuehner
2009-09-21 11:10shuehnerNote Added: 0020227
2009-09-21 11:10shuehnerStatusnew => feedback
2009-09-22 16:07mondalaciNote Added: 0020273
2009-09-29 15:00shuehnerNote Added: 0020528
2009-09-29 15:48mondalaciNote Added: 0020533
2009-09-29 15:51shuehnerNote Added: 0020534
2009-09-29 15:54mondalaciNote Added: 0020535
2009-09-29 15:59shuehnerNote Added: 0020536
2009-09-29 19:46mondalaciNote Added: 0020546
2009-09-30 00:00psarobeStatusfeedback => closed
2009-09-30 00:00psarobeResolutionopen => no change required
2009-09-30 11:44shuehnerRelationship addedrelated to 0010817
2009-09-30 11:45shuehnerRelationship addedrelated to 0010818
2009-10-01 00:00anonymoussf_bug_id0 => 2871024

Notes
(0020171)
rafaroda   
2009-09-18 08:07   
Stefan,

Can you please comment on this issue?

Thanks.
(0020227)
shuehner   
2009-09-21 11:10   
Hi mondalaci,

i did never notice this really slow client side processing. The only really noticable latency i know is caused by the ajax request roundtrip to the server. These happen on:

1.) each select of another record (to update the attachment icon in the toolbar for the selected record)
2.) on reload of the next dataset to be shown when scrolling far enough

Could you please double check that you don't have the requests from item 1.) happening? And please clarify what your definition of 'some rows' is for the grid (100, 10.000, 1.000.000) ?
(0020273)
mondalaci   
2009-09-22 16:07   
Hi Stefan,

First of all, I did not realize that requests are happening in the background because I was looking for XMLHttpRequests in Firebug, but I couldn't see anything. As soon as I realized that the JS gets loaded into a frame I could observe them using LiveHTTPHeaders.

Speaking of the requests that happen upon record selection, I can see them looking for attachment information. Is it possible to load this information along with the records? I've seen users scrolling with the arrow keys and this approach would be much faster in such cases.

Regarding the dataset loading requests it'd be useful to be able to fine tune the number of the preloaded records. For example, I browse in several grids quite often spanning relatively large distances and I'd rather prefer a slightly longer preload and much smoother interaction afterwards. Are there any plans regarding this setting?

Thanks!
(0020528)
shuehner   
2009-09-29 15:00   
Hi mondalaci,

i think the background requests you are seeing now do explain your delays on scrolling and page-switching. Even if the numbers you mention i.e. 2s for scrolling are still really bad (If the 2seconds latency does happen on scrolling down a single record)...

The other two ideas you mention look like good valid feature requests:
1.) Preload the attachment icon info with the records loaded (but then you'll no live updated while scrolling)
2.) Changeable preload buffer size for grid windows

The second one you should be able to do globally now, by changing the WADGrid.java file underneath the src-wad/ directory. Look inside the file for bufferSize which is by default defined to be three pages (of the number of visible rows).

If you agree please open this two feature requests, then we can link them to this defect and close this defect and track the issues in the feature requests.
(0020533)
mondalaci   
2009-09-29 15:48   
Stefan,

I understand everything you wrote except this:

"1.) Preload the attachment icon info with the records loaded (but then you'll no live updated while scrolling)"

What you mean by "you'll no live updated while scrolling"?

By preloading the attachment info for the records I think that the attachment icon can be updated purely through the DOM instead of using AJAX, right?
(0020534)
shuehner   
2009-09-29 15:51   
Hi,

what i mean is that after loading the group of records (i.e. 3 visible pages) we will not send of ajax-requests per selected record change (i.e. cursor down), so if another user adds an attachment your attachment icon will not be immediately updated if you scroll to this record. Only on the next loading cycle of the records (i.e. scroll down long way and back, or reload the window).

Right now you get the updated icon immediately when you scroll to the record.
(0020535)
mondalaci   
2009-09-29 15:54   
Wow, you've just set the world record by answering within 3 minutes :)

I understand what you mean. I think this deficiency is acceptable in most cases.

I'll fill the two related feature requests soon.

Thanks!
(0020536)
shuehner   
2009-09-29 15:59   
OK,

please give me a note here with the two new issues, i'll wait with closing this defect until we added the links to the new issues.
(0020546)
mondalaci   
2009-09-29 19:46   
I've just reported:

* https://issues.openbravo.com/view.php?id=10817 [^]
* https://issues.openbravo.com/view.php?id=10818 [^]

So you can close this report.

Thanks!