0

This is a very bizarre any very frustrating issue so please bear with me for the full explanation.

PREEMPTIVE NOTE: This is not a question of how to improve DOM/CSS for performance. You will see when you read the frustrations.

We have recently re-worked out website to be cross-browser (e.g. < !DOCTYPE html >)

After all the pain HTML and CSS re-factoring, we thought things were fine. However our website which has a pretty heavy DOM is incredibly sluggish to the point of being unusable. Example: clicking to select a row takes 10 seconds until it is highlighted and its check-box is checked.

Frustrations:

1) This sluggishness is not universal. Only IE9 suffers from this. IE8, IE10, FireFox, Chrome are all speedy!

2) IE9 itself if changed in debugger to IE8 documents mode becomes speedy! But not in its own IE9 mode.

3) While we are noticing the some sluggishness, the SUPER sluggishness (to the point of unusable) is only on specific machines.

4) Of course, one of those machines is a client.

The Question:

What could possibly unique about specific machines to cause super sluggishness? What could cause these machines to suffer more than others?

Things we've checked:

1) Windows 7 fully updated.

2) We do not have Windows update KB2976627 installed

3) We do not have Windows update KB2670838 installed

4) Disabled all Add-ons

5) Stress again that we disabled Shockwave Flash Object.

6) Tried disabling "Software Rendering" in Internet Options so that the GPU is used.

7) Reduced Windows display quality settings to run for maximum performance.

Additional Edvidence:

When the display area gets smaller, responsiveness increases. This happens when the browser window itself is made smaller or when dragged partly outside the screen boundaries. Also when performance improves as DOM elements removed/hidden.

DynaTrace shows a huge amount of time spent on rendering.

Webpage content:

There is ONLY: HTML, CSS2, JavaScript, JQuery, simple images.

  • JqGrid 4.5.2

  • JQuery 1.4.2

  • JQuery-UI 1.8.2

There is NONE of the following: Flash, video, CSS3, loaded third-party web content.

Machines tried:

OS: Windows 7 Enterprise N 64bit RAM: 2 GB CPU: 2.53 Ghz (2 processors)

OS: Windows 7 Enterprise 64bit RAM: 8 GB CPU: 2.67 Ghz (2 processors)

IE9 Version:

9.0.8112.16421 64-bit IE9 Update Version: 9.0.31 (KB2977629)

We tried uninstalling update KB2977629 with no improvement.

Repeat of Question:

What could possibly unique about specific machines to cause super sluggishness? What could cause these machines to suffer more than others?

Cœur
  • 37,241
  • 25
  • 195
  • 267
amirsk
  • 11
  • 1
  • 6
  • Sorry, but the question have no value for other if you will not include **really important parts of your solution**. At the beginning **which versions of jqGrid, jQuery UI and jQuery you use?** The next **how you use jqGrid?** You don't included any **examples of jqGrid options and callbacks which you use**. You can append your question at least with an URL of one demo which reproduces the problem. – Oleg Oct 22 '14 at 11:21
  • A real example link is not possible. I am using JqGrid 4.5.2 - but although it worsens the performance - I am unsure if it is specific to JqGrid or only that it is a sizable part of the DOM. I said already that the DOM and CSS is heavy. We have about 800 DOM elements (of which JqGrid is ~300) and 3000+ CSS rules (including from jquery-ui and jqgrid). Yes, I known, I known bad. We're working on it. But you are not reading the question I stated twice. Why are SPECIFIC seemingly random machines of Win7 and IE9 suffering while most Others are okay(ish)? – amirsk Oct 22 '14 at 12:03
  • I explicitly stated in my question the improving DOM/CSS efficiency is not the objective. First to understand what is up with Win7 IE9. Do you think configurations of JqGrid is enough to make this question irrelevant? – amirsk Oct 22 '14 at 12:11
  • jqGrid 4.5.2 is old, but probably updating to the 4.6.0 will no fix along the problem. Nevertheless if you can reproduce the problem on some from your computers I would recommend you to make one test with temporary replacing jqGrid 4.5.2 to 4.6.0 just to be sure. **You still don't post which versions of jQuery UI and jQuery you use?** In any way you should append your question with an example which shows **how you fill jqGrid**. **At least one code fragment which shows how you create jqGrid is really required**. – Oleg Oct 22 '14 at 13:07
  • Here are the versions. But I am afraid of wandering off topic. Sure we want to upgrade and fix our other CSS, but first we need to see if there is a fast explanation for the client why specific machines are effected. THe upgrade will actually be high effort (long story). So I want to see what we might not have tried in the Win7 IE9 system to get us out of immediate hot water. Like I said most machines are fine if a little sluggish. – amirsk Oct 22 '14 at 13:17
  • JqGrid 4.5.2, JQuery 1.4.2, JQuery-UI 1.8.2 – amirsk Oct 22 '14 at 13:20
  • For understanding of my point of view: I suppose that you created grid in one not the best way. So rendering of the grid is slow and it's especially slow in IE9 Win7. Nevertheless I suppose that the origin of the problem is in not the best choice of jqGrid options or the implementation of callbacks. In any way **at least one code fragment which shows how you create jqGrid is really required.** – Oleg Oct 22 '14 at 13:24
  • Additionally I would recommend you update jQuery 1.4.2 published **February 19, 2010** to more recent versions. It could be at least jQuery 1.8.3 and jQuery UI 1.8.24 or better the current jQuery 1.11.1 with jQuery UI 1.11.2 and jQuery Migrate 1.2.1 which will fix different possible compatibility problems in your existing code. You should understand that old jQuery and jQuery UI were written at the time of **old web browser**. *If you need support the current versions of web browsers too then you really have to update jQuery and jQuery UI to more recent versions.* – Oleg Oct 22 '14 at 13:37
  • 1
    You should understand that jQuery 1.4.2 was published at the time of IE8 and FF 3.6. If you want support IE9-IE11, Firefox, Chrome, Safari and Opera in current versions you should update jQuery. If you need support IE 6/7/8 then it should be jQuery 1.11.1. If you need support IE starting with IE9 it should be more quick and small jQuery 2.1.1. **The remarks about update of jQuery and jQuery UI have common nature and there are probably not the main problem which you have.** – Oleg Oct 22 '14 at 13:48
  • I will try the upgrades. FYI I was previously mistaken. We use jquery1.7.2 (still not latest) and we have an **empty** 1.4.2 to prevent apparent collisions with the newer jquery. I will prepare a code fragment for you. I just am hoping someone can provide a possible explanation for the specific machines super slowness so until we stabilize the upgrades the client will be able to work. Again, I acknowledge general sluggishness in IE9 which the upgrades _might_ resolve, but with those specific exceptions it was generally tolerable for the client. Thanks for sticking around. Will update you soon. – amirsk Oct 23 '14 at 05:28
  • Initial attempted upgrade working. jQuery 2.1.1,jQuery-UI 1.11.2,JqGRid 4.6.0. A lot of our styling has been lost (as expected with any upgrade but could have been worse). It will take time to get it back. In the meantime performance has improved - though that may be due to all the missing styling. The specific machines benefited but they are still slower than the other machines. Row click takes 3 seconds until it checks the check-box. So the original question is still relevant regardless of the performance improvement. @Oleg what specific code fragments would be the most informative to you? – amirsk Oct 23 '14 at 08:37
  • The code of one jqGrid is required. Till now I have **absolutely no idea what you do**. Which `datatype` you use? How many rows has the grid. Do you use `gridview: true` option or not? How you fill it? Do you fill the grid with pure data or with HTML fragments generated on the server? Do you use `autoencode: true` option? Do you use local/remote paging? Do you use virtual scrolling (scroll:1)? How many rows contains the grid totally? Which value have `rowNum`? Do you make some modification of the rows during/after loading of the grid (in `loadComplete`, `gridComplete`, `afterInsertRow`)?... – Oleg Oct 23 '14 at 08:50
  • I don't now at least whether all your grids are TreeGrids, grids with grouping, subgrids etc. Some people for example calls in the loop inside of `loadComplete` inline editing of every row and don't write about it in the question. There are really a lot of options how one can use jqGrid to make all very slowly. So one can't help if absolutely no implementation information is provided. – Oleg Oct 23 '14 at 08:54
  • To make you more optimistic I suggest to look at [the demo](http://www.ok-soft-gmbh.com/jqGrid/performane-90000_.htm) which I created for [the answer](http://stackoverflow.com/a/26121503/315935). It loads 90000 rows and still works very quickly. The time in ms for loading will be displayed in alert dialog on opening of the demo. – Oleg Oct 23 '14 at 09:03
  • I am not sure if this is supposed to make me optimistic or less. Yous example runs fast on the 'special machine'. Which may indicate that the issue is not solely JqGrid. It could be all the extra content we put into JqGrid but let me share some details to maybe shed some light: – amirsk Oct 23 '14 at 10:56
  • 1) some of our tables have subgrids, the core example does not. – amirsk Oct 23 '14 at 10:58
  • I don't understand what you mean under "Yous example runs fast on the 'special machine'". Do you have a machine where it runs slowly and where the displayed time is large? I still waiting for the code of one jqGrid which is slow in IE9 on some computer... – Oleg Oct 23 '14 at 11:23
  • 2) some of our tables have grouping, the core example does not 3) scroll not referenced 4) autoencode not referenced 5) loadComplete and afterInsertRow not used 6) gridview: true (when no subgrid) 7) gridComplete used only to check usecase of there being no data 8) datatype: "local" 9) not cell editing 10) cells contain HTML generated on the client side based on metadata. In our case, the cells are a mix of simple strings, links and icon gifs 11) there are only 20 rows displayed with about 15 columns 12) all paging is done on the server so only 20 are loaded – amirsk Oct 23 '14 at 11:25
  • 'special' as in very sluggish for us while other machine run fine. You example runs fast on the very sluggish machine. – amirsk Oct 23 '14 at 11:27
  • **How many rows contains the grid totally on the server?** (100, 1000, 1000000000)? How you fill the grid? Do you use `data` parameter or `addRowData` in the loop or using `tableToGrid` or in any other way? I don't think that the problem can be solved if you don't post the code of the grid which have the problem (on some computers and with some other restriction). – Oleg Oct 23 '14 at 15:17
  • The server could have 10 or millions or records. The grid on the client only knows about 20 at any given time. We use `data` and we set `rowNum:100` because we give the end user an option of loading 100. But this is not the general use case and not the situation we are testing here - only 20. – amirsk Oct 26 '14 at 06:22
  • BTW, I remind you that the issue of performance is **not** load time but afterwards. Mouse hover and click over rows taking up to 10 seconds. – amirsk Oct 26 '14 at 06:29
  • I see no sense to continue the discussion if you don't post the code of the grid which have the problem. I posed you URL with the grid which loads 90000 rows very quickly and, how you can confirm, no problem exist on your "bad" computer. So I do believe that the problem in *how you use or how you fill the grid*. If you would provide the demo (in jsFiddle for example) which reproduces the problem (one need load *only one page of your data* and you can replace the data to some test one) then the solution of the problem could be probably quickly found. – Oleg Oct 26 '14 at 07:27

1 Answers1

0

I discovered the explanation. As I feared when I phrased the original question JQGrid was a distraction (red herring). The real cause was answered in another stack overflow article.

In short, our page contains a lot of rounded corners (i.e. border-radius) styling. And there is a bug in IE9 that causes the rendering engine to choke on this. Once this styling was removed, everything was speedy again!

This also explains why IE8 browsers and even using IE9 with IE8 documents mode were fast. IE8 does not support border-radius so it didn't fall into this issue.

Community
  • 1
  • 1
amirsk
  • 11
  • 1
  • 6