5 ms·
Are you sure about that? When I profile it in chrome, about 50% of the time is spent in the garbage collector and "(program)". Randomly pausing the debugger mos
by cpncrunch 10y ago
Are you sure about that? When I profile it in chrome, about 50% of the time is spent in the garbage collector and "(program)". Randomly pausing the debugger most hits the ad code, which I think is what is causing the problem. It seems to be constantly loading and displaying the same ad over and over again, or something dumb along those lines.
The irony is that there are only two small, mostly static adverts on the entire friggin page.
Anyway, debugging this webpage was much more interesting than the article itself :)
- tomxor 10y agoprogram is native function calls, often poorly performing animations look like this, the connection is not immediately apparent because the calling function looks like it takes a disproportionately and innocently small amount of CPU time. Admittedly I did not check further so maybe i'm wrong, but that function is at the top of the list for the JavaScript code, if it's GC the connection is easier to establish because you can look at the objects on the heap and see if they are created by that function... if it's native canvas or webGL on the other hand I find I usually have to change the code to find the relationship... maybe there are more advanced ways, I know there is way more to chromiums dev tools that what I use. I too pissed to dig deeper... why couldn't the site authors be bothered to properly debug some animation code that is clearly runaway.
- cpncrunch 10y agoTypinganimationframe wasnt on the list for me. Just lots of calls using small amounts of time. Its the animation thats causing the gc and program time.