Loading ...
Sorry, an error occurred while loading the content.

YUI and IE 6 performance

Expand Messages
  • Brian McCullough
    Folks, I know I have been repeating variations of this question lately, but, unfortunately, not everybody in the world has seen the light and converted to
    Message 1 of 8 , Apr 22 12:02 PM
    • 0 Attachment
      Folks,

      I know I have been repeating variations of this question lately, but,
      unfortunately, not everybody in the world has seen the light and
      converted to Firefox!

      I have been doing more testing of my application, and seeing some
      significant issues. For instance, the CPU usage goes to 100% for
      fairly long periods of time, and the memory footprint also tends to grow
      over time.

      A little background:

      Using YUI modules:

      TabView
      RTE
      DataTable
      Connection Manager
      Container ( Overlay and Dialog )

      also ( dependencies )

      Button, Event, Menu, JSON


      One question springs to mind to start:

      When I switch tabs, I ask for replacement contents for the pane ( or at
      least the "variable" part ) from the server. That contents is prepared
      as an HTML block, and in the client that is attached as the innerHTML of
      a DIV with a known ID. I am guessing that IE's JS processor does not
      free the previous contents of that DIV, but instead just adds memory to
      hold the new contents. I know that I have been told that innerHTML is
      NOT the way to do this, but other things have caused the re-design to
      get delayed. Could I, as a stopgap, if the answer to the memory
      question is true, "walk the DOM" prior to attaching the innerHTML, and
      delete all of the children?



      Another question:

      I know I have read articles describing various ways of attaching and
      processing events, whether directly to the element in question ( button,
      etc. ), or at the top of the DOM ( the bubbling method ). I seem to
      have a combination of the two. One thing that I noticed was that just
      moving the mouse cursor around the screen, passing over the various
      tabs and other elements on the screen, seemed to cause a great deal of
      CPU activity. Is it ( or is there any real answer ) more efficient to
      attach all of my event handlers at the top of the DOM or as near to the
      trigger element as possible? This could have different answers
      depending on whether you are talking about code efficiency or execution
      efficiency, I suspect. I, and the users, are most concerned with
      "response."


      At present, it is taking more than half a minute to just load the
      application, and 10-30 seconds to change tabs.

      I KNOW that I have not done things in the most efficient manner in some,
      or many, cases, and expect that there are some things that I can do to
      improve this in the short term, before the complete re-design that is
      planned.


      Thank you,
      Brian
    • viruschidai
      Hi, try to compress the javascripts and contents.
      Message 2 of 8 , Apr 23 11:55 PM
      • 0 Attachment
        Hi,

        try to compress the javascripts and contents.


        --- In ydn-javascript@yahoogroups.com, Brian McCullough <bdmc@...> wrote:
        >
        > Folks,
        >
        > I know I have been repeating variations of this question lately, but,
        > unfortunately, not everybody in the world has seen the light and
        > converted to Firefox!
        >
        > I have been doing more testing of my application, and seeing some
        > significant issues. For instance, the CPU usage goes to 100% for
        > fairly long periods of time, and the memory footprint also tends to grow
        > over time.
        >
        > A little background:
        >
        > Using YUI modules:
        >
        > TabView
        > RTE
        > DataTable
        > Connection Manager
        > Container ( Overlay and Dialog )
        >
        > also ( dependencies )
        >
        > Button, Event, Menu, JSON
        >
        >
        > One question springs to mind to start:
        >
        > When I switch tabs, I ask for replacement contents for the pane ( or at
        > least the "variable" part ) from the server. That contents is prepared
        > as an HTML block, and in the client that is attached as the innerHTML of
        > a DIV with a known ID. I am guessing that IE's JS processor does not
        > free the previous contents of that DIV, but instead just adds memory to
        > hold the new contents. I know that I have been told that innerHTML is
        > NOT the way to do this, but other things have caused the re-design to
        > get delayed. Could I, as a stopgap, if the answer to the memory
        > question is true, "walk the DOM" prior to attaching the innerHTML, and
        > delete all of the children?
        >
        >
        >
        > Another question:
        >
        > I know I have read articles describing various ways of attaching and
        > processing events, whether directly to the element in question ( button,
        > etc. ), or at the top of the DOM ( the bubbling method ). I seem to
        > have a combination of the two. One thing that I noticed was that just
        > moving the mouse cursor around the screen, passing over the various
        > tabs and other elements on the screen, seemed to cause a great deal of
        > CPU activity. Is it ( or is there any real answer ) more efficient to
        > attach all of my event handlers at the top of the DOM or as near to the
        > trigger element as possible? This could have different answers
        > depending on whether you are talking about code efficiency or execution
        > efficiency, I suspect. I, and the users, are most concerned with
        > "response."
        >
        >
        > At present, it is taking more than half a minute to just load the
        > application, and 10-30 seconds to change tabs.
        >
        > I KNOW that I have not done things in the most efficient manner in some,
        > or many, cases, and expect that there are some things that I can do to
        > improve this in the short term, before the complete re-design that is
        > planned.
        >
        >
        > Thank you,
        > Brian
        >
      • Caridy Patino
        Hello Brian, very interesting questions. I will try to address both: 1. In the case of dynamic areas, tabview: Removing DOM element is not the problem, the
        Message 3 of 8 , Apr 29 9:46 AM
        • 0 Attachment
          Hello Brian, very interesting questions. I will try to address both:

          1. In the case of dynamic areas, tabview:

          Removing DOM element is not the problem, the references are. If you change the content of the element (using innerHTML) and there is not a single reference (DOM refs) to an element within that area, the old content will be release it.

          In the dispatcher implementation, I addressed this using purgeElement (from YUI Event). Analyzing all the child elements, cutting all the listeners, and then replacing the content with the new one. This will avoid leaks on IE.

          There is another issue with the memory, and this is something that affects web apps, particularly memory consumption. Every time that you store a reference to a DOM element, and you remove that element from the DOM, a fragment of the DOM will be created. And you can keep using that reference even when you replace the content using innerHTML. This means that if you have a tab the get refreshed every 2minutes, and during that process you store certain references to an element in the new DOM structure, you will be creating a lot of overhead, consuming more and more memory with every request.

          And this is actually related with the second question:

          2. Is it better to bubble up or to set the listener as close to the target as possible?

          Well, this is something that we need to analyze. It's hard to profile it, because each app is different, but there are few things that I want to comment:

          - If the event bubbles up (like a click), the browser will do it anyway. So putting a listener at the top will not create an overhead at this point.

          - The problem is the amount of checks that you have to do in the listener to identify the target. Usually for clicks this is straight forward, but with mouseout/in, things can get a little slow. And of course, depends of the DOM structure for each page as well.

          Best Regards,
          Caridy

          --- In ydn-javascript@yahoogroups.com, Brian McCullough <bdmc@...> wrote:
          >
          > Folks,
          >
          > I know I have been repeating variations of this question lately, but,
          > unfortunately, not everybody in the world has seen the light and
          > converted to Firefox!
          >
          > I have been doing more testing of my application, and seeing some
          > significant issues. For instance, the CPU usage goes to 100% for
          > fairly long periods of time, and the memory footprint also tends to grow
          > over time.
          >
          > A little background:
          >
          > Using YUI modules:
          >
          > TabView
          > RTE
          > DataTable
          > Connection Manager
          > Container ( Overlay and Dialog )
          >
          > also ( dependencies )
          >
          > Button, Event, Menu, JSON
          >
          >
          > One question springs to mind to start:
          >
          > When I switch tabs, I ask for replacement contents for the pane ( or at
          > least the "variable" part ) from the server. That contents is prepared
          > as an HTML block, and in the client that is attached as the innerHTML of
          > a DIV with a known ID. I am guessing that IE's JS processor does not
          > free the previous contents of that DIV, but instead just adds memory to
          > hold the new contents. I know that I have been told that innerHTML is
          > NOT the way to do this, but other things have caused the re-design to
          > get delayed. Could I, as a stopgap, if the answer to the memory
          > question is true, "walk the DOM" prior to attaching the innerHTML, and
          > delete all of the children?
          >
          >
          >
          > Another question:
          >
          > I know I have read articles describing various ways of attaching and
          > processing events, whether directly to the element in question ( button,
          > etc. ), or at the top of the DOM ( the bubbling method ). I seem to
          > have a combination of the two. One thing that I noticed was that just
          > moving the mouse cursor around the screen, passing over the various
          > tabs and other elements on the screen, seemed to cause a great deal of
          > CPU activity. Is it ( or is there any real answer ) more efficient to
          > attach all of my event handlers at the top of the DOM or as near to the
          > trigger element as possible? This could have different answers
          > depending on whether you are talking about code efficiency or execution
          > efficiency, I suspect. I, and the users, are most concerned with
          > "response."
          >
          >
          > At present, it is taking more than half a minute to just load the
          > application, and 10-30 seconds to change tabs.
          >
          > I KNOW that I have not done things in the most efficient manner in some,
          > or many, cases, and expect that there are some things that I can do to
          > improve this in the short term, before the complete re-design that is
          > planned.
          >
          >
          > Thank you,
          > Brian
          >
        • Brian McCullough
          ... Hi Caridy, Thank you for your ( potentially ) useful response. I have some plans to do some fairly major restructuring to the project, and start making
          Message 4 of 8 , Apr 29 12:31 PM
          • 0 Attachment
            On Wed, Apr 29, 2009 at 04:46:16PM -0000, Caridy Patino wrote:
            > Hello Brian, very interesting questions. I will try to address both:

            Hi Caridy,

            Thank you for your ( potentially ) useful response. I have some plans
            to do some fairly major restructuring to the project, and start making
            use of Dispatcher. I am hoping that that will improve matters. The IE
            6 version is deadly slow, while the Firefox and IE 7 version flys. They
            both use the same code, with the only difference being that the Firefox
            version uses YUI Loader to load the libraries, while the IE 6 version
            uses either individual references or the Combo loader. This may change
            the initial load time, but after that is done there shouldn't be any
            difference.


            I will probably ask more questions as I get working on the Dispatcher
            changes.


            Thanks,
            Brian
          • vinay12
            We are using YUI 2.5.1 on IE6. Our application is supporting only IE6 but we are still running it on Firefox to debug and make best use of firebug. We had been
            Message 5 of 8 , Jun 1, 2009
            • 0 Attachment
              We are using YUI 2.5.1 on IE6. Our application is supporting only IE6 but we
              are still running it on Firefox to debug and make best use of firebug.
              We had been experiencing varying response time on different users machine.
              Some users had response time of 12 secs on IE and 4 secs on Firefox while
              others had 5 sec on IE and 3 sec on firefox.
              We are still trying to figure out if it is network issues or viruses which
              is causing this varying response time but overall the response time has been
              much better on Firefox.

              Has this been the case with other users also or or we missed out some
              performance tips for IE 6 ?


              --
              View this message in context: http://www.nabble.com/YUI-and-IE-6-performance-tp23821480p23821480.html
              Sent from the ydn-javascript mailing list archive at Nabble.com.
            • Satyam
              The difference in response times in between IE and Firefox are normal, IE is considerably slower than all of the rest of the browsers. The difference in
              Message 6 of 8 , Jun 1, 2009
              • 0 Attachment
                The difference in response times in between IE and Firefox are normal,
                IE is considerably slower than all of the rest of the browsers. The
                difference in times in between different machines, I cannot tell.

                Satyam


                vinay12 escribió:
                > We are using YUI 2.5.1 on IE6. Our application is supporting only IE6 but we
                > are still running it on Firefox to debug and make best use of firebug.
                > We had been experiencing varying response time on different users machine.
                > Some users had response time of 12 secs on IE and 4 secs on Firefox while
                > others had 5 sec on IE and 3 sec on firefox.
                > We are still trying to figure out if it is network issues or viruses which
                > is causing this varying response time but overall the response time has been
                > much better on Firefox.
                >
                > Has this been the case with other users also or or we missed out some
                > performance tips for IE 6 ?
                >
                >
                >
                > ------------------------------------------------------------------------
                >
                >
                > No virus found in this incoming message.
                > Checked by AVG - www.avg.com
                > Version: 8.5.339 / Virus Database: 270.12.48/2148 - Release Date: 06/01/09 06:09:00
                >
                >
              • vinay12
                But a difference of 4-8 seconds to load the same page does not look normal. I guess the way memory is allocated to DOM objects could be one of the causes of
                Message 7 of 8 , Jun 1, 2009
                • 0 Attachment
                  But a difference of 4-8 seconds to load the same page does not look normal.
                  I guess the way memory is allocated to DOM objects could be one of the
                  causes of the problem but not very sure about it.




                  Satyam-3 wrote:
                  >
                  > The difference in response times in between IE and Firefox are normal,
                  > IE is considerably slower than all of the rest of the browsers. The
                  > difference in times in between different machines, I cannot tell.
                  >
                  > Satyam
                  >
                  >
                  > vinay12 escribió:
                  >> We are using YUI 2.5.1 on IE6. Our application is supporting only IE6 but
                  >> we
                  >> are still running it on Firefox to debug and make best use of firebug.
                  >> We had been experiencing varying response time on different users
                  >> machine.
                  >> Some users had response time of 12 secs on IE and 4 secs on Firefox while
                  >> others had 5 sec on IE and 3 sec on firefox.
                  >> We are still trying to figure out if it is network issues or viruses
                  >> which
                  >> is causing this varying response time but overall the response time has
                  >> been
                  >> much better on Firefox.
                  >>
                  >> Has this been the case with other users also or or we missed out some
                  >> performance tips for IE 6 ?
                  >>
                  >>
                  >>
                  >> ------------------------------------------------------------------------
                  >>
                  >>
                  >> No virus found in this incoming message.
                  >> Checked by AVG - www.avg.com
                  >> Version: 8.5.339 / Virus Database: 270.12.48/2148 - Release Date:
                  >> 06/01/09 06:09:00
                  >>
                  >>
                  >
                  >

                  --
                  View this message in context: http://www.nabble.com/YUI-and-IE-6-performance-tp23821480p23822323.html
                  Sent from the ydn-javascript mailing list archive at Nabble.com.
                • Satyam
                  The ratio in between the performance of IE and others is normal and it is not due to the transmission of the data from server to client but the manipulation of
                  Message 8 of 8 , Jun 1, 2009
                  • 0 Attachment
                    The ratio in between the performance of IE and others is normal and it
                    is not due to the transmission of the data from server to client but the
                    manipulation of the DOM and rendering. With the DataTable, that
                    generates lots of DOM elements you see big increases in performance just
                    doing client side paging, where the amount of data transmitted remains
                    the same but less is rendered each time.

                    So, what I meant to say is don't concentrate in the different
                    performance in between IE and others because that is normal. IE is
                    relatively slow and that's that, nothing you can do about it, except
                    making lighter pages, which will affect all browsers in the same
                    proportion though in absolute terms, IE is the one that will benefit the
                    most.

                    Why the difference in between the two machines, that I don't know.

                    Satyam


                    vinay12 escribió:
                    > But a difference of 4-8 seconds to load the same page does not look normal.
                    > I guess the way memory is allocated to DOM objects could be one of the
                    > causes of the problem but not very sure about it.
                    >
                    >
                    >
                    >
                    > Satyam-3 wrote:
                    >
                    >> The difference in response times in between IE and Firefox are normal,
                    >> IE is considerably slower than all of the rest of the browsers. The
                    >> difference in times in between different machines, I cannot tell.
                    >>
                    >> Satyam
                    >>
                    >>
                    >> vinay12 escribió:
                    >>
                    >>> We are using YUI 2.5.1 on IE6. Our application is supporting only IE6 but
                    >>> we
                    >>> are still running it on Firefox to debug and make best use of firebug.
                    >>> We had been experiencing varying response time on different users
                    >>> machine.
                    >>> Some users had response time of 12 secs on IE and 4 secs on Firefox while
                    >>> others had 5 sec on IE and 3 sec on firefox.
                    >>> We are still trying to figure out if it is network issues or viruses
                    >>> which
                    >>> is causing this varying response time but overall the response time has
                    >>> been
                    >>> much better on Firefox.
                    >>>
                    >>> Has this been the case with other users also or or we missed out some
                    >>> performance tips for IE 6 ?
                    >>>
                    >>>
                    >>>
                    >>> ------------------------------------------------------------------------
                    >>>
                    >>>
                    >>> No virus found in this incoming message.
                    >>> Checked by AVG - www.avg.com
                    >>> Version: 8.5.339 / Virus Database: 270.12.48/2148 - Release Date:
                    >>> 06/01/09 06:09:00
                    >>>
                    >>>
                    >>>
                    >>
                    >
                    >
                    > ------------------------------------------------------------------------
                    >
                    >
                    > No virus found in this incoming message.
                    > Checked by AVG - www.avg.com
                    > Version: 8.5.339 / Virus Database: 270.12.48/2148 - Release Date: 06/01/09 06:09:00
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.