I don't think your timer would create a lot of lag by collecting one
or two objects on a twenty second interval.
Where the DOM extension functions really slow you down is in
iteration. I recently was building a date chooser gadget and I was
using the "down" method for retrieving a cell by row index and column
index. In an iteration over the table this slowed things down
extremely. Granted this is a rather extreme case of iteration and DOM
functions, but it does have a cost that will add up on you.
>But I don't really have anything to compare it against.
You don't have to compare it against anything, if it slows down your
interface look to improve things. If you can see it lag it is taking
too long, anything over 200 ms and your users will notice.
On Sep 18, 10:41 am, Tom Gregory <[EMAIL PROTECTED]> wrote:
> Make sure you try it in more than just Firefox, which has excellent
> speed due to built-in XPath functions.
>
> You may also want to try variations on your CSS selector; for
> example, add the id of a parent node so only a subset of the document
> is searched.
>
> TAG
>
> On Sep 18, 2007, at 7:29 AM, jarrod wrote:
>
>
>
> > Well here you go, I learn something new every day.
>
> > console.profile('double$');
> > var pe = new PeriodicalExecuter(function(){
> > var c = [];
> > c = $$('div.myStyle');
> > },5)
> > console.profileEnd('double$');
>
> > I set the profiler to run every 5 seconds while I played with the
> > interface, changed the DOM, etc... repeatedly, I got times in the
> > <20ms range. Most times registered at 0ms. So either the profiler is
> > broken, or the DOM is cached and can be parsed extremely quickly.
>
> > To really stress the $$() function, I also tested this:
>
> > console.profile('double$');
> > var c = [];
> > for (var i=0; i<100; i++) {
> > c = $$('div.myStyle');
> > }
> > console.profileEnd('double$');
>
> > That registered a time of only 202ms, so that's not bad.
>
> > Thanks for the help!
>
> > On Sep 18, 8:57 am, jarrod <[EMAIL PROTECTED]> wrote:
> >> No - and I hadn't thought of that. I can benchmark it. But I don't
> >> really have anything to compare it against.
>
> >> I just wondered if - theoretically - the $$ operation was expensive.
>
> >> Let me see what benchmarking says...
>
> >> On Sep 18, 8:52 am, Michael Peters <[EMAIL PROTECTED]> wrote:
>
> >>> jarrod wrote:
> >>>> But it occurred to me that $$ could be a computationally expensive
> >>>> operation to be running every second.
>
> >>> Ummm... did you benchmark it?
>
> >>> --
> >>> Michael Peters
> >>> Developer
> >>> Plus Three, LP
--~--~---------~--~----~------------~-------~--~----~
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@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
