I've done some testing and here's the results.  Warning - this post is a 
little long.  The executive summary though is that it doesn't appear to 
be ClueTip at fault here...

First, I commented out the hoverIntent include.  Initially it seemed a 
bit more responsive, but this appears to be a perception on my part or 
the current state of my computer memory.

So I did further testing, taking Brian's suggestion to drop timing code 
in place.  This is a little harder to isolate because I'm using the 
native ClueTip Ajax support.  (Sorry Karl, a local element isn't 
suitable in this case.. :).  Here's how I added the timing code:

1. Added an onActivate paramter to the Cluetip call with the following:
onActivate : function () {
   base = new Date();
   var stamp = new Date();
   diff = stamp.getTime() - base.getTime();
   console.log("activate: " + stamp.getTime() + "  diff: " + diff ) ;
   return true;
},

("base" and "diff" are defined as global variables for this testing.)

2. Added a click event handler to the element with the following:
.click( function () {
   var stamp = new Date();
   diff = stamp.getTime() - base.getTime();
   console.log("clicked: " + diff); });
}

3. Added the following to my onShow function :
var stamp = new Date();
diff = stamp.getTime() - base.getTime();
console.log("Showing: " + stamp.getTime() + "  diff: " + diff);


Now, when I ran this code on the first test page I got the following output:
1: activate: 1199435163464 diff: 1
2: GET 
http://win/jobtrax/crew2/xhr/dayDetails.cfm?e=303&sd=1-Jan-2008&d=1-Jan-2008 
(75ms)jquery-1.2.1.pack... (line 11)
3: clicked: 876
4: Showing: 1199435164953 diff: 1490

(I added the line numbers manually here to help visually)

So this tells me that it took 876 ms to get to the click event, and 
1490ms to go through the onShow function.

Here's what I get for that page when calling the cached data:

1: activate: 1199435315111 diff: 0
2: Showing: 1199435315637 diff: 526
3: clicked: 589

(rather reasonable...)

But then I noticed that this particular test page had a single cluetip 
popup instance on it.  So I shifted my date range to show more realistic 
data where there are a couple hundred instances on the page.  Here's the 
results of that data:

1: activate: 1199435420837 diff: 0
2: GET 
http://win/jobtrax/crew2/xhr/dayDetails.cfm?e=348&sd=26-Feb-2007&d=26-Feb-2007 
(92ms)jquery-1.2.1.pack... (line 11)
3: clicked: 1485
4: Showing: 1199435423496 diff: 2659

So 2659 ms to show the popup.  Here's the same cached popup:

1: activate: 1199435521195 diff: 0
2: Showing: 1199435522314 diff: 1119
3: clicked: 1195

Still 1119 seconds to get through the onShow routine, even though the 
data is cached.  (I'm assuming this is due to the mentioned 
innefficiencies in my code - which I'll fix in a bit.. :)

So, I purposely tested this on an element that would show me more than 
one item in the popup (the day had 2 tasks, so I was viewing 2 task 
details).  So I thought I should compare this to another day that showed 
a single detail item in the popup (which was true for the first run of 
the timing).  Here's what I got for that:

1: activate: 1199435799489 diff: 1
2: GET 
http://win/jobtrax/crew2/xhr/dayDetails.cfm?e=276&sd=20-Feb-2007&d=20-Feb-2007 
(129ms)jquery-1.2.1.pack... (line 11)
3: clicked: 1504
4: Showing: 1199435802187 diff: 2699

And the same with cached data:
1: activate: 1199435861078 diff: 0
2: Showing: 1199435862148 diff: 1070
3: clicked: 1146

So what I see here is that there is little difference between the one or 
two item popup - they have similar times for both the Ajax call and the 
cached data.  But it would appear my onShow function is the culprit in 
that it still takes 1+ seconds to do the processing.

So then I changed my code as Karl suggested (thanks Karl - that actually 
made sense to me.. :) and re-ran the same tests.  For the first test, it 
shaved 200ms off the times.  But for the remaining tests all the numbers 
were very similar to the original tests.

I'm not sure if my testing method is can give me a definitive answer on 
where the delays are coming from.  But it would appear to be my code (I 
think), and not ClueTip per se.  But I find it odd that I'm still seeing 
  one second before my Ajax indicator is made visible, even though the 
delays *seem* to be related to the Ajax call.

On the plus side, I met with my customer today and they changed their 
mind about that slow running SQL on their own.  They want that moved off 
to a dedicated report.  (phew).  So all this is going to get much faster 
regardless...

While this email is long, I find it very helpful when I have to explain 
what I'm doing.  It forces me to double check things - especially my 
assumptions - and this particular one has ended with me absolving 
Cluetip of any part of my delays. :)  (so it seems at least).  If you 
see any problems with my testing or conclusions, please let me know. 
Otherwise, I hope the numbers help in some way to make Cluetip better.. :)

Thanks for the support guys!

Shawn


Karl Swedberg wrote:
> 
> Hi Shawn,
> 
> On the clueTip end of things, there shouldn't be any delay, really, 
> because the code isn't doing a whole lot other than positioning the 
> tooltip. One thing you could try is to pull out the reference to the 
> hoverIntent plugin in the page's <head>. I know you set all the 
> hoverIntent params to 0, but this might be a good sanity check. The ajax 
> stuff is just using jQuery's built-in $.ajax() method.
> 
> Not sure whether this would be feasible in your situation, but you can 
> also grab clueTip contents from an element on the current page by 
> setting "local: true".
> 
> The onShow function could be made more efficient, but I doubt this will 
> affect the delay:
>  onShow : function (ct, c) {
>   $("#dayDetailTip").children('.taskdetail')
>     .unbind("click")
>     .click(function () {
>       var id = this.id.toString().split("-")[1];
>       task.edit(id);
>       $("#cluetip-close").click();
>   })
>     .filter(':even').css({backgroundColor: '#ddd'}).end()
>     .filter(':odd').css({backgroundColor: '#fff'}).end();
> }
> 
> 
> Hope that helps a bit.
> 
> 
> --Karl
> _________________
> Karl Swedberg
> www.englishrules.com
> www.learningjquery.com
> 
> 
> 
> On Jan 2, 2008, at 10:39 PM, McLars wrote:
> 
>>
>> I don't know anything about the clueTip. Hopefully, someone else can
>> help you with that. Are you sure Ajax is necessary, though?  You say
>> you want the application to be snappy (a laudable goal), but it sounds
>> like there is a bit of a speed hit with the database. So, even if you
>> get the Ajax to fire sooner, I'd think that could still make the
>> response slow--especially if your users are very remote.
>>
>> It would probably feel more responsive if the tip info was preloaded.
>> If it takes too long to get the tip info while the server is building
>> the initial page, perhaps you could fire off an Ajax query for the
>> entire page's tips as soon as the DOM is ready. There will probably be
>> bit of a time while the user is reading the page before they start
>> hovering over stuff.
>>
>> Overall, you can get more data out of a database faster in one chunk
>> rather than separate calls for each date. Unless you really have a lot
>> of dates on the page, it might be faster to just get them all at once.
>> For example, if you had a month calendar, that would only be 31 days
>> of data. Even a year's worth might not be bad if each record is small.
>> Since you're talking about tips, I'm guessing it isn't much. Ajax is
>> best suited for when there is either just too much data to load at
>> once or the data might change during the lifetime of the page. You are
>> right to focus on the user experience. Do what's best for them, not
>> what's cool to program.
>>
>> If you wanted to get fancy, you could have the page load up with the
>> dates slightly grayed and then light them up as the data is loaded.
>> That way the users can start reading the page right away, and they can
>> see that activity is going on in the background.
>>
>> Larry
>>
>>
>> On Jan 2, 4:28 pm, Shawn <[EMAIL PROTECTED]> wrote:
>>> I'm seeing an odd delay before the Cluetip code fires.  I'm wondering if
>>> I have cluetip configured badly, or if the problem is elsewhere in my
>>> code (most likely, but need to check...).  Here's the Cluetip code:
>>>
>>> $(this).attr("rel", "xhr/dayDetails.cfm").cluetip({
>>>    activation : "click",
>>>    positionBy: "mouse",
>>>    mouseOutClose: true,
>>>    sticky: true,
>>>    closePosition: "title",
>>>    ajaxSettings : {
>>>      type: "GET",
>>>      data: "e=" + eid + "&sd=" + dt + "&d=" + dt
>>>    },
>>>    onShow : function (ct, c) {
>>> $("#dayDetailTip").children(".taskdetail:even").css("background-color",
>>> "#fff");
>>> $("#dayDetailTip").children(".taskdetail:odd").css("background-color",
>>> "#ddd");
>>> $("#dayDetailTip").children(".taskdetail").unbind("click").click(function 
>>>
>>> () {
>>>                     var id = this.id.toString().split("-")[1];
>>>                     task.edit(id);
>>>                     $("#cluetip-close").click();
>>>                   });
>>>    }
>>>
>>> });
>>>
>>> What I'm seeing is a 1 or 2 second delay before my Ajax activity
>>> indicator (via .ajaxStart() ) shows up.  SO, that would seem to mean
>>> that nothing is happening for that 1 or 2 second period.  I would assume
>>> the Ajax via ClueTip would fire almost instantly??
>>>
>>> I know it's only a second or two, but it makes the application feel
>>> sluggish.  The called Ajax page (dayDetails.cfm) already is doing stuff
>>> with the database that incurs a performance penalty.  So This delay just
>>> adds to it.  (And I'm looking at the SQL side of things to see if I can
>>> speed it up.  Not promising though - it's a non-trivial task).
>>>
>>> If it helps, I do have the hoverIntent plugin loaded (as well as a bunch
>>> more).  I have tried setting the hoverintent delay to 0 with no effect.
>>>
>>> Thanks for any tips.
>>>
>>> Shawn
> 

Reply via email to