I''ve got a page I''ve implemented a bunch of observables and
sortables. There are around 330 items in the list. The Observables
(for hide/show of sublists) don''t seem to impact performance, but the
Sortables take a very long time to load when the page is refreshed or
submitted--even after accounting for the server-side processing and
latency. I''ve actually saved this off as a static page and tested
it''s loading. It''s taking an average of 15-20 seconds to
process the
page''s javascript. When I removed the Sortables code (see below), the
page loads very quickly. About 60 Sortable.create()s are called.
Here''s a snippet of a Sortable:
Sortable.create("group_2297",{ghosting:true,constraint:false,
onUpdate:function(sortable){window.location =
"ReorderWebCategory.action?groupIdsKey=group_2297&" +
Sortable.serialize(sortable) + "&toggleLevel=" + toggleLevel +
"#2297";
new Effect.Pulsate(sortable);},
onChange:function(sortable){$(sortable.style.backgroundColor =
"#ffff00");}
});
I''ve executed this page in IE on Windows, Firefox on Windows and Mac,
and Safari on the Mac, all with similar results.
I''m looking for a way to improve the performance--it makes an
otherwise cool interface pretty unusable. Here''s a movie of it so you
can see it in action with latency and all:
http://www.dangdev.com/movies/webcategories_01.mov
Thanks for any feedback.
Jamie
correct me if i''m wrong, but by the look of the UI, the sorting is only within subcategories. so instead of creating them all at once at the beginning, you could create them only when the user expands a top level category. On 10/13/05, Jamie Orchard-Hays <jamie@dang.com> wrote:> > I''ve got a page I''ve implemented a bunch of observables and > sortables. There are around 330 items in the list. The Observables > (for hide/show of sublists) don''t seem to impact performance, but the > Sortables take a very long time to load when the page is refreshed or > submitted--even after accounting for the server-side processing and > latency. I''ve actually saved this off as a static page and tested > it''s loading. It''s taking an average of 15-20 seconds to process the > page''s javascript. When I removed the Sortables code (see below), the > page loads very quickly. About 60 Sortable.create()s are called. > > Here''s a snippet of a Sortable: > > > Sortable.create("group_2297",{ghosting:true,constraint:false, > onUpdate:function(sortable){window.location > "ReorderWebCategory.action?groupIdsKey=group_2297&" + > Sortable.serialize(sortable) + "&toggleLevel=" + toggleLevel + "#2297"; > new Effect.Pulsate(sortable);}, > onChange:function(sortable){$(sortable.style.backgroundColor > "#ffff00");} > }); > > I''ve executed this page in IE on Windows, Firefox on Windows and Mac, > and Safari on the Mac, all with similar results. > > I''m looking for a way to improve the performance--it makes an > otherwise cool interface pretty unusable. Here''s a movie of it so you > can see it in action with latency and all: > > http://www.dangdev.com/movies/webcategories_01.mov > > Thanks for any feedback. > > Jamie > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20051013/2848e166/attachment.html
That''s an interesting idea. I actually have the page loading with everything expanded, but I was thinking I''d make it like it first appears in the movie--where they are all collapsed. The only issue here, is that the page would still take the hit as soon as one of the "show" links is clicked. Maybe instead of opening a whole level, it would just expand the children of one category. It would certainly mitigate some of the performance problems. As a side note, this experience has made me think that with the proliferation of AJAX-enabled pages, we''re all going to be screaming for much better performing javascript engines in our browsers. Jamie On Oct 13, 2005, at 12:57 PM, Troy Hakala wrote:> correct me if i''m wrong, but by the look of the UI, the sorting is > only within subcategories. so instead of creating them all at once > at the beginning, you could create them only when the user expands > a top level category. > > On 10/13/05, Jamie Orchard-Hays <jamie@dang.com> wrote: > I''ve got a page I''ve implemented a bunch of observables and > sortables. There are around 330 items in the list. The Observables > (for hide/show of sublists) don''t seem to impact performance, but the > Sortables take a very long time to load when the page is refreshed or > submitted--even after accounting for the server-side processing and > latency. I''ve actually saved this off as a static page and tested > it''s loading. It''s taking an average of 15-20 seconds to process the > page''s javascript. When I removed the Sortables code (see below), the > page loads very quickly. About 60 Sortable.create()s are called. > > Here''s a snippet of a Sortable: > > > Sortable.create("group_2297",{ghosting:true,constraint:false, > onUpdate:function(sortable){ window.location > "ReorderWebCategory.action?groupIdsKey=group_2297&" + > Sortable.serialize(sortable) + "&toggleLevel=" + toggleLevel + > "#2297"; > new Effect.Pulsate(sortable);}, > onChange:function(sortable){$(sortable.style.backgroundColor > "#ffff00");} > }); > > I''ve executed this page in IE on Windows, Firefox on Windows and Mac, > and Safari on the Mac, all with similar results. > > I''m looking for a way to improve the performance--it makes an > otherwise cool interface pretty unusable. Here''s a movie of it so you > can see it in action with latency and all: > > http://www.dangdev.com/movies/webcategories_01.mov > > Thanks for any feedback. > > Jamie > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20051013/afc023cb/attachment.html
True! Maybe in your special case (that many sortables) you''ll need a specialized implementation that caches some of the stuff to get decent performance. The Draggables go a long way to ensure that they work correctly in most circumstances, so given a specific page layout, many of the checks they do could be done away with. Sadly, the DOM is missing some functions that would really speed up things and clean up the code, like a function to just return an elements coordinates relative to the page origin, so many calculations the browser has already done (to render the element correctly) have to be redone by the JavaScript code by traversing DOM constructs (and while doing that checking for various browser bugs, and so on and so forth...). Anyway, improving the performance (where possible) is one of the top things on my list for a future 2.0 release of script.aculo.us. Thomas Am 13.10.2005 um 19:20 schrieb Jamie Orchard-Hays:> As a side note, this experience has made me think that with the > proliferation of AJAX-enabled pages, we''re all going to be > screaming for much better performing javascript engines in our > browsers. >
Thanks much, Thomas. Any suggestions as to where to start with speeding up my code? You mention caching, and Draggable checks. Jamie On Oct 13, 2005, at 1:29 PM, Thomas Fuchs wrote:> True! > > Maybe in your special case (that many sortables) you''ll need a > specialized implementation that caches some of the stuff to get > decent performance. The Draggables go a long way to ensure that > they work correctly in most circumstances, so given a specific page > layout, many of the checks they do could be done away with. > > Sadly, the DOM is missing some functions that would really speed up > things and clean up the code, like a function to just return an > elements coordinates relative to the page origin, > so many calculations the browser has already done (to render the > element correctly) have to be redone by the JavaScript code by > traversing DOM constructs (and while doing that checking for > various browser bugs, and so on and so forth...). > > Anyway, improving the performance (where possible) is one of the > top things on my list for a future 2.0 release of script.aculo.us. > > Thomas > > Am 13.10.2005 um 19:20 schrieb Jamie Orchard-Hays: > > >> As a side note, this experience has made me think that with the >> proliferation of AJAX-enabled pages, we''re all going to be >> screaming for much better performing javascript engines in our >> browsers. >> >> > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >
I''ve found that a nested UL will not show applied animations
(specifically
BlindUp). Has anyone else run into this?
For example:
<ul>
<li>Test
<ul id="test">
<li>Test</li>
</ul>
</li>
</ul>
//this will work
New Effect.BlindDown($(''test''));
//this won''t
New Effect.BlindUp($(''test''));
I just got back to this after upgrading to HEAD yesterday. The Toggles aren''t working anymore in my app (I was on head from about a week before). Has anything intentionally been changed in its functionality? Jamie On Oct 13, 2005, at 1:48 PM, Jamie Orchard-Hays wrote:> Thanks much, Thomas. Any suggestions as to where to start with > speeding up my code? You mention caching, and Draggable checks. > > Jamie > > > On Oct 13, 2005, at 1:29 PM, Thomas Fuchs wrote: > > >> True! >> >> Maybe in your special case (that many sortables) you''ll need a >> specialized implementation that caches some of the stuff to get >> decent performance. The Draggables go a long way to ensure that >> they work correctly in most circumstances, so given a specific >> page layout, many of the checks they do could be done away with. >> >> Sadly, the DOM is missing some functions that would really speed >> up things and clean up the code, like a function to just return an >> elements coordinates relative to the page origin, >> so many calculations the browser has already done (to render the >> element correctly) have to be redone by the JavaScript code by >> traversing DOM constructs (and while doing that checking for >> various browser bugs, and so on and so forth...). >> >> Anyway, improving the performance (where possible) is one of the >> top things on my list for a future 2.0 release of script.aculo.us. >> >> Thomas >> >> Am 13.10.2005 um 19:20 schrieb Jamie Orchard-Hays: >> >> >> >>> As a side note, this experience has made me think that with the >>> proliferation of AJAX-enabled pages, we''re all going to be >>> screaming for much better performing javascript engines in our >>> browsers. >>> >>> >>> >> _______________________________________________ >> Rails-spinoffs mailing list >> Rails-spinoffs@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >