[dojo-contributors] dojo.moduleUrl slow?

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
that.

James

_Url and the current implementation of moduleUrl comes into use when you are
using modules outside the usual directory (siblings to dijit, dojo etc)
which is a common use case when you are using dojo as a shared toolkit, in a
directory/path inaccessible to the developer. Or when you are needing to
resolve paths from inline script in a page rather than from a module.
It may not be truly necessary for the dojo and dijit modules, but it
shouldnt go away entirely.

Sam

This is one of the reasons I'm not a fan of dojo._Url, it felt slow

OK, just to clarify: I do not want dojo.moduleUrl() to go away, for
the reasons you mention. I just want it to do a simple dot-to-path
conversion on the first argument, then append the second argument to
that result. Basically not use dojo._Url internally. But we would
probably see if that breaks people's expectations of getting back a
dojo._Uri object from dojo.moduleUrl(). For the majority case (99%?)
the dojo._Uri object is not really wanted, just the path that you get
via dojo._Uri's toString method. And it does not seem like collapsing
the ../ references are really that important in those cases either.

James

As has been discussed multiple times in multiple tickets, _Url is
there in the package system (and in moduleUrl()) because otherwise
both IE and FF get very, very confused about what url they are
actually relative to when you're loading new code.

If you have a credible solution to *that* problem, I think we can talk
about removing _Url.

Regards

We may not be able to get rid of dojo._Url completely (given the
loader-related issue), but removing dojo.moduleUrl's dependency on it
will help dojo.moduleUrl's performance, and it will lessen our
dependency on dojo._Url.

It is important to limit our use of dojo._Url so that we can
realistically consider moving it out of base (once the loader-related
issue is resolved).

James