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?

Search Discussions

  • James Burke at Nov 10, 2007 at 12:50 am

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

    James
  • Sam foster at Nov 11, 2007 at 10:03 am
    _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
    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20071111/39f0468d/attachment.htm
  • James Burke at Nov 11, 2007 at 11:22 pm
    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
    On Nov 11, 2007 7:03 AM, sam foster wrote:
    _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
    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


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Alex Russell at Nov 12, 2007 at 2:34 am
    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
    On Nov 11, 2007, at 8:22 PM, James Burke wrote:

    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
    On Nov 11, 2007 7:03 AM, sam foster wrote:
    _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
    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


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Nov 12, 2007 at 10:20 am
    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
    On Nov 11, 2007 11:34 PM, Alex Russell wrote:
    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

    On Nov 11, 2007, at 8:22 PM, James Burke wrote:

    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
    On Nov 11, 2007 7:03 AM, sam foster wrote:
    _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
    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


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at dojotoolkit.org
    http://dojotoolkit.org/mailman/listinfo/dojo-contributors

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedNov 9, '07 at 7:00p
activeNov 12, '07 at 10:20a
posts6
users4
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase