>The relatively long time spent in new date() worried me, as this would introduce a large chunk of (possibly even skewed) Heisenbug side effects into perf measuring and most attempts to optimize behaviour by dynamic worker spawning.
>
>First googling attempt brought up
>
http://ejohn.org/blog/accuracy-of-javascript-time/>and from there I found
>
http://ejohn.org/blog/javascript-benchmark-quality/>which is quite logical and reminded me of 20odd years ago enhancing my perf framework built for fpw even after vfp profiler was around...
>For those who do not realize, who the author is: besides the blog he programs, for instance creating jQuery - so I hunted his site a bit further than usual given a specific question ;-)
>My immediate fear of implementing something based on QueryPerformance for Windows and similar routines for mobile for a couple of browsers were somewhat hightened by
>
http://ejohn.org/blog/javascript-testing-does-not-scale/>but then I remembered all the headway done in JS speed since V8 entered the scene and changed Google search parameters, resulting me to find eventually:
>
https://www.w3.org/TR/2013/REC-user-timing-20131212/>And the event timing based on that for common DOM events was shown to be implemented on mobile, Chrome, FF, Safari and newer IE
>(no link, that one was found mobile)
>
>Pretty certain that calling into those methods does NOT result in such a heavy duration, but did not test myself - just wanted to mention it to you and Viv ;-)
>
>>I do not have benchmarks nor do I have time to do so.
>
>I can see benefit and danger in that ;-) But you might consider another approach: Remember sometimes users complaining about unresponsive
>UT or load times several factors longer than expected from usual behaviour - often Al, as some of his professional habits and concerns bleed over here?
>
>
https://www.w3.org/TR/2013/REC-performance-timeline-20131212/#sec-window.performance-attribute>
https://www.w3.org/TR/2014/REC-progress-events-20140211/>
https://www.w3.org/TR/2016/WD-resource-timing-20160225/>
>If you had a routine in place collecting those high-performance-timered event sequences into a string to be back.posted by those participating in such a measurement routine you would get a MUCH better picture of the events happening. Adding timing info on the client side query string
causing that reaction, you could even reflect that client info back in the new string to have a baseline info to compare the events happening on your answer to that post.
>
>Also this would provide you within a few weeks with enough info to look for patterns of slow answers. If / when you want to optimize, you do it based on realistic data, invaluably better than to hunt only after sporadic posts - been there, done similar in desktop apps ;-)))
>
>If you decide to try that path, make such timing plus backposting the info user selectable. I for one (knowing the extent and reason) would participate - not giving an explanation and way to opt out might do more than raise a few eyebrows (esp. in the old world), as the practice of learning more about users and user expirience is seen quite critical these days here in Europe.
>
>Thierry can chime in and tell us, whether he has such an option already in place in his package - might be even more important for him ;-)
>At least you do have an option in place to provide solid info about round trip time cost from client side click on new tree link until the DOM events you deem necessary have fired. Which can be a GREAT stopper for somewhat unfocused discussions about performance that sometimes originates with clients ;-))
>
>my 0.22€ (have expirience in timing&measurement) + HTH
Thanks for a very detailed answer.
I have found that this does not occur as before, but, now, only after a much longer period. I stil have other performance adjustments I can do. Then, if it persists, I will have to apply benchmarks to see about other places which can be a factor. I will also have to go through all those links you just provided.
