On Nov 9, 2007 4:00 PM, Bill Keese wrote:
According to http://trac.dojotoolkit.org/ticket/5060#comment:3,
dojo.moduleUrl() is very slow. That surprising to me, and concerning
since the code has about 200 references to it.
Do you think that's an opportunity for caching based on the first arg
(which is always "dijit" in my case)?
Probably this only affects non-builds?
I think the problem is the usage of dojo._Url in dojo.moduleUrl().
In an optimization path at work, I looked at dojo.uri.moduleUri() in
0.4.3 (the ancestor of dojo._Url()). We noticed lots of calls to this
function, but the majority use case (in our case the 100% use case),
all we really needed was to do the "foo.bar" translation to "foo/bar"
and then append the other path argument to that string. We were not
concerned with condensing the ../ references in the URL (the browser
worked them out), so we did that change to get a performance boost. I
don't recall the actual boost, but it was measurable (this change was
done after some "bigger" optimizations).
This is one of the reasons I'm not a fan of dojo._Url, it felt slow
and takes up space in dojo base. I think Alex did a performance change
extracting out the regexps so they are compiled once, but it still
seemed expensive, particularly since I am not aware of our code
actually needing all of the normalization and decomposition into url
properties that it does. I am interested in just converting it to do
the dot-to-slash path conversion and appending the other path part to