Opened 10 years ago

Closed 8 years ago

#16435 closed defect (patchwelcome)

loader performance issue in compat mode compared to 1.6

Reported by: Patrick Ruzand Owned by: Rawld Gill
Priority: undecided Milestone: 1.11
Component: Loader Version: 1.8.1
Keywords: Cc: Martin Vlk, ben hockey, niallmur, cjolif, mkeane
Blocked By: Blocking:


With the new amd loader, a layer built with 1.6 compat mode takes much more time to be loaded and defined than with the 1.6 loader.

The scenario is this one.

  • using either 1.7.4 or 1.8.1,
  • a layer is built with the following build options:

compat: "1.6", noref: 1,

  • the modules included in the layer use the require/define api
  • then, the built layer code is updated to include some instrumentation code to measure the time it takes to process the layer code and resolve all the modules (that is, something like:
    startTime = ...
    // ...the layer code here...
    endTime = ...
    duration = endTime-startTime;
  • in a html file, the loader is configure in legacy mode (async:0),
  • and the layer is loaded with a <script> tag (which should work since we are in compat mode and insertAbsMids is truthy)

Since we are in compat mode, all the modules in the layer are defined immediatly.
For comparison, the same is done with a 1.6 dojo distrib, the layer contents is exactly the same in term of modules, except the modules included in the layer use dojo.require/dojo.provide api.

For the sake of simplicity, in the testcase I run, the layer includes only modules from dojo/dojox/dijit. Also, I verified that the layer is "self contained", that is, no dependencies is missing which would have distorted the measures.

Attached are the profiles I used to define my layer, the layers, and html test files. The path to dojo.js needs to be updated.

Results are the following (all browsers show the same increase)
1.6.1: FF16: 25ms ; IE8: 40ms
1.7.4: FF16: 80ms ; IE8: 200ms
1.8.1: FF16: 83ms ; IE8: 220ms

This seems to be a significant regression in term of performance (with real impact on IE8).

Attachments (3) (119.6 KB) - added by Patrick Ruzand 10 years ago.
layers, profiles and html files (143.1 KB) - added by Patrick Ruzand 10 years ago.
tests for 1.8 (115.7 KB) - added by Patrick Ruzand 9 years ago.
absmid layer

Download all attachments as: .zip

Change History (18)

Changed 10 years ago by Patrick Ruzand

Attachment: added

layers, profiles and html files

Changed 10 years ago by Patrick Ruzand

Attachment: added

tests for 1.8

comment:1 Changed 10 years ago by Patrick Ruzand

Cc: Martin Vlk added

comment:2 Changed 10 years ago by ben hockey

Cc: ben hockey added

comment:3 Changed 10 years ago by Patrick Ruzand

Cc: niallmur added

comment:4 Changed 10 years ago by Patrick Ruzand

Priority: undecidedhigh

comment:5 Changed 10 years ago by Patrick Ruzand

rawld, did you have time by chance to look at this issue ? I may have missed something obvious, but I can't explain why there're so much differences between the 2 tests in 1.6 and 1.7/8. From the numbers, my feeling would be that the require() machinary is more costly than the old 1.6 one, even in compatibility mode, but I am really not sure, and if it's indeed the case, I think a workaround or fix would be great. Of course, if you need more info on this, do not hesitate to ask me.

comment:6 Changed 9 years ago by cjolif

Cc: cjolif added

comment:7 Changed 9 years ago by Rawld Gill

Milestone: tbd1.9
Priority: highundecided
Status: newassigned
Type: defectenhancement

I spent some time profiling this tonight on FF and chrome (I don't have IE8 available this week). I do see the degradation in performance when 1.6 is compared to 1.8. The functions that compute module relative paths, mapping, paths (different than relative paths), aliases, and non-module URLs seem to be what's causing the perf hit. There is a lot of computation going on there--every module id in every dependency vector (about 2000 for this big app)--which the 1.6 API is not required to do. So, there will be some performance loss. On both chrome and ff I see going from about 20ms to about 90ms. It doesn't surprise me that IE8 with it's slower JS engine does much worse.

Isn't even the reported delta of 160ms is very small compared to download time? If it isn't, then isn't the total time not my the 2x user reaction time (about 200ms)? I'm have some trouble understanding why this is a critical issue. Could you expand?

All that said, I'll continue to look at the algorithms to see if I can tweak some more perf as well as use this as a good test case for improving build strategies.

Keeping open until I can definitively say what I can do with algorithms in 1.9

comment:8 Changed 9 years ago by Martin Vlk

Hi, I initiated the creation of this report because of performance degradation we had experienced when going from Dojo 1.4 to 1.7 with our large application.

I would like to add some context here highlighting why this is an issue in some real life scenarios even if it might not look so significant in the provided test page.

One point is that we find module loading is heavily dependent on CPU speed and not all users have fast machines. We have done extensive testing on a range of hardware and on a "5 years old" spec machine (which is our benchmark base) the time to load layer of similar size with IE8 is ~1000ms.

Our application in particular is structured in such a way that we are hit by this performance degradation badly. In many cases on clicking a button in the application 2 pages must be loaded in iframes, each of them loads this big layer file. So we are ending up with ~1650ms increase in load time due to this issue compared with Dojo 1.4.

Also I would like to comment on the above point about degradation being small compared to download time. Isn't it the case that files are downloaded once and cached by browser, which means that most of the time download time is (close to) zero?

Martin Vlk

comment:9 Changed 9 years ago by Patrick Ruzand

Cc: mkeane added

comment:10 Changed 9 years ago by Patrick Ruzand

Following the dojo-meeting discussion, I did the test with only absolute mid in the layer, and the numbers are almost the same... (I have attached the updated layer (uncompressed) ).

Changed 9 years ago by Patrick Ruzand

Attachment: added

absmid layer

comment:11 Changed 9 years ago by bill

Milestone: 1.91.10
Type: enhancementdefect

Punting as per meeting. This would be scary to fix since we already released beta and since it probably involves big code changes.

Could also close as wontfix since 2.0 won't have a compat mode.

comment:12 Changed 8 years ago by Patrick Ruzand

Milestone: 1.101.11

Postpone it to 1.11.

(Note as bill mentioned, it should be closed as wontfix IMO).

comment:13 Changed 8 years ago by bill

Anyone object to closing this as wontfix?

comment:14 Changed 8 years ago by Patrick Ruzand

(on behalf of mvlk1, who is the one that initially reported the issue)

Hi, while I see it's futile I'll object anyway, because lots of applications will undoubtedly stay on pre-V2.0 Dojo for a long time and this fix would make them work faster.

In our case we have a large application used by many customers and this issue is affecting us a lot. It is unclear when or if at all we will be able to switch to Dojo 2.0, because from what I have seen it will essentially mean a rewrite of the application.

We are happy to offer help with testing after a fix here, so if at all possible please do fix this issue.


comment:15 Changed 8 years ago by bill

Resolution: patchwelcome
Status: assignedclosed

I'm going to close this as patchwelcome, because it seems very unlikely that Rawld will fix it. If someone has a patch, we'll take a look.

Note: See TracTickets for help on using tickets.