Rails spinoffs - Oct 2007 - Is there a point where javascript objects become too large to handle?

Hello,

I am writing a webapp that has the potential to hold a fairly large
amount of data in one object.  The object  will be a multidimensional
array, representing a hierarchical structure at four levels deep.  At
the leaf level, I am expecting an average of 1000-2000 objects
containing ~20 strings/integers.  In the worst case, I think this
number could increase to 7000.

My testing so far is _nowhere_ near those numbers, and I have begun to
wonder if I will encounter problems of scale in the future.  Do you
expect that I will have browser crashing or slow-down?

Also, I will need to serialize this array (Object.toJSON() ?) and send
it back to the server.  Will either the serialization process, or the
transmission be a problem as well?

Thank you,
phrygius


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

phrygius wrote:
> ...
> My testing so far is _nowhere_ near those numbers, and I have begun to
> wonder if I will encounter problems of scale in the future.  Do you
> expect that I will have browser crashing or slow-down?
> ...
I have an "offline" application that starts out by loading ~200kb of 
JSON data into JavaScript objects.  I have found that IE6 is the most 
feeble browser when it comes to large amounts of html, but it scales 
pretty well with JavaScript memory.  The things that don''t scale well
on
_IE6_ are:


1. DOM size: I originally tried a large document instead of the 200kb of 
JSON where I used JavaScript to show/hide relevant data for different 
actions.  In IE this was very slow to load and add observers (over 5 
minutes for 500kb of html and consuming 90MB RAM) and seemed to slow 
down exponentially as DOM size increased.  I ended up storing JavaScript 
objects in memory and setting innerHTML of content panes based on html 
templates.

2. appendNode(): Building html strings and calling innerHTML is 3 to 5 
times faster than createElement() and appendNode() (and innerHTML is 
standard in html5!)

3. Iteration using each(): With extremely large arrays and objects, for 
and while loops are a must.

4. Sorting: Don''t even _try_ to sort large arrays in IE6.

5. Objects instead of arrays: I found that using objects like 
associative arrays takes up too much memory--use numerically indexed 
arrays instead.

6. ActiveX Filters: You can easily crash IE6 if you use ActiveX PNG 
transparency filters on more than a handful of images on a page.


After making changes along these lines, the application is very 
responsive in IE6.  I also didn''t experience any noticeable slowdowns 
when unserializing the initial JSON data or serializing the result data 
for posting back to the server.  Serialization in IE6 is definitely 
slower than in Firefox, but was not a problem for me.

The crazy thing is that all my tests showed Firefox scaling very well.  
With 500kb of html and thousands of Event.observe() and each() calls and 
sorting of large objects, Firefox took only about 3 seconds.

When testing IE6 with 500kb of HTML, I never got it to crash, but I did 
get the "Script is running slowly" warning--which to users looks like
a
catastrophic error :)

Happy coding

- Ken
 Snyder

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for sharing your results Ken!  I''m just crossing my fingers and
hoping my IT Dept will have pushed IE7 out by the time my app goes
live :)

Thanks again,
phrygius


On Oct 3, 12:39 pm, Ken Snyder
<kendsny...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> phrygius wrote:
> > ...
> > My testing so far is _nowhere_ near those numbers, and I have begun to
> > wonder if I will encounter problems of scale in the future.  Do you
> > expect that I will have browser crashing or slow-down?
> > ...
>
> I have an "offline" application that starts out by loading ~200kb
of
> JSON data into JavaScript objects.  I have found that IE6 is the most
> feeble browser when it comes tolargeamounts of html, but it scales
> pretty well with JavaScript memory.  The things that don''t scale
well on
> _IE6_ are:
>
> 1. DOM size: I originally tried alargedocument instead of the 200kb of
> JSON where I used JavaScript to show/hide relevant data for different
> actions.  In IE this was very slow to load and add observers (over 5
> minutes for 500kb of html and consuming 90MB RAM) and seemed to slow
> down exponentially as DOM size increased.  I ended up storing JavaScript
> objects in memory and setting innerHTML of content panes based on html
> templates.
>
> 2. appendNode(): Building html strings and calling innerHTML is 3 to 5
> times faster than createElement() and appendNode() (and innerHTML is
> standard in html5!)
>
> 3. Iteration using each(): With extremelylargearrays and objects, for
> and while loops are a must.
>
> 4. Sorting: Don''t even _try_ to sortlargearrays in IE6.
>
> 5. Objects instead of arrays: I found that using objects like
> associative arrays takes uptoomuch memory--use numerically indexed
> arrays instead.
>
> 6. ActiveX Filters: You can easily crash IE6 if you use ActiveX PNG
> transparency filters on more than a handful of images on a page.
>
> After making changes along these lines, the application is very
> responsive in IE6.  I also didn''t experience any noticeable
slowdowns
> when unserializing the initial JSON data or serializing the result data
> for posting back to the server.  Serialization in IE6 is definitely
> slower than in Firefox, but was not a problem for me.
>
> The crazy thing is that all my tests showed Firefox scaling very well.  
> With 500kb of html and thousands of Event.observe() and each() calls and
> sorting oflargeobjects, Firefox took only about 3 seconds.
>
> When testing IE6 with 500kb of HTML, I never got it to crash, but I did
> get the "Script is running slowly" warning--which to users looks
like a
> catastrophic error :)
>
> Happy coding
>
> - Ken
>  Snyder

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---