Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#12456 closed defect (fixed)

dojox.gfx: Performance degradation in version 1.6 in IE ‎(VML)

Reported by: yehuda Owned by: Patrick Ruzand
Priority: high Milestone: 1.7
Component: DojoX GFX Version: 1.6.0
Keywords: gfx, IE, VML Cc:
Blocked By: Blocking:

Description

Performance in IE7 and IE8 (VML) has deteriorated dramatically in version 1.6 of dojox.gfx compared to 1.5

To reproduce the issue, I used the 100 circles demo http://download.dojotoolkit.org/release-1.6.0/dojo-release-1.6.0/dojox/gfx/demos/circles.html and added some timers inside the code. I ran each test with 50, 100, 150, and 200 circles using version 1.5 and 1.6 and found that performance gets exponentially bad as the number of circles get large. See the numbers below and the attached graph showing the response time as a function of the number of circles and dojo's version.

Dojo 1.5: 50 circles in 0.13 seconds; 100 circles in 0.25 seconds; 150 circles in 0.41 seconds; 200 circles in 0.56 seconds Dojo 1.6: 50 circles in 0.69 seconds; 100 circles in 2.69 seconds; 150 circles in 6.14 seconds; 200 circles in 11.75 seconds

This looks like a side-effect of the fix to #9624

Attachments (3)

VMLperformance.png (22.4 KB) - added by yehuda 8 years ago.
Performance degradation in dojox.gfx 1.6
vmlAdd.patch (2.9 KB) - added by Patrick Ruzand 8 years ago.
Fix as discussed at dojoconf. Behavior can be chosen via the config.fixVmlAdd flag. Default is to enable the patched behavior. false revert to 1.5 impl (solve perf. issue, but might be buggy)
vmlAdd-2.patch (2.9 KB) - added by Patrick Ruzand 8 years ago.
After some discussions, seems more natural to have the performance-friendly behavior by default. Reworked patch accordingly (set fixVmlAdd to true to enable #9624 fix)

Download all attachments as: .zip

Change History (9)

Changed 8 years ago by yehuda

Attachment: VMLperformance.png added

Performance degradation in dojox.gfx 1.6

comment:1 Changed 8 years ago by Chris Mitchell

Milestone: tbd1.7

comment:2 Changed 8 years ago by Kenneth G. Franqueiro

I don't suppose there's any chance of this getting looked at for 1.7 considering how late in the cycle we are? I've seen a number of threads on the mailing list by people running into this, it's quite unfortunate if it remains an issue for another whole cycle.

comment:3 Changed 8 years ago by Chris Mitchell

Owner: changed from Eugene Lazutkin to Patrick Ruzand

Discussed with Eugene and Patrick at Dojo conf. This is an important defect to fix before 1.7 ga. Rather than backing out #9624, we will default behavior to the fully functional #9624 behavior, but add a config setting to disable 9624 for VML.

Changed 8 years ago by Patrick Ruzand

Attachment: vmlAdd.patch added

Fix as discussed at dojoconf. Behavior can be chosen via the config.fixVmlAdd flag. Default is to enable the patched behavior. false revert to 1.5 impl (solve perf. issue, but might be buggy)

comment:4 Changed 8 years ago by Eugene Lazutkin

The patch is totally fine --- exactly in line with what we discussed. Please commit it.

Changed 8 years ago by Patrick Ruzand

Attachment: vmlAdd-2.patch added

After some discussions, seems more natural to have the performance-friendly behavior by default. Reworked patch accordingly (set fixVmlAdd to true to enable #9624 fix)

comment:5 Changed 8 years ago by Patrick Ruzand

Resolution: fixed
Status: newclosed

In [26722]:

fix performance regression. #9624 patch should now be explicitly enabled via a djConfig flag (fixVmlAdd:true), disabled by default., fixes #12456, refs #9624

comment:16 Changed 7 years ago by Patrick Ruzand

In [28142]:

backport vml perf regression patch, refs #12456.

Note: See TracTickets for help on using tickets.