Ornelaz: Unfortunately this is not really a thing the profiler can help you with all that much

Ornelaz: You should use the debugger for this.

Rowson: Here is my entire setup for this form. http://fiddle.jshell.net/2931d7vt/8/

Abilez: Thousands of js lines of code :

Ornelaz: Put a breakpoint in the caching function

Biscari: I can’t find it, the code is pretty spaghettish

Bonds: Bfig: ouch. Good luck with that, then, you’re going to need it.

Wede: K2gremlin, you didn’t change anything

Birky: Bfig: you can either step through the code, or modify the code to collect information/log/etc.

Keneally: Is there any chrome/js tool that could help me get useful stats for this?

Trusso: But if the code is all spaghetti, you can’t really infer what are the things you need to care about

Hallinger: Holy *****, 7 million reads?

Bouvier: K2gremlin, http://fiddle.jshell.net/2931d7vt/10/

Ornelaz: You can attach an event listener breakpoint on xhr stuff

Ornelaz: In the chrome debugger

Ornelaz: Not 100% sure that will help you

Borum: To explain what I mean, there seems to be one place where all the calls are made, so i know which function is the final culprit. The problem is this function is called several times with cached and/or prefetched parameters

Brinckerhoff: I don’t intend to fix the whole code architecture, that would mean rewriting everything, I just want to find the biggest time sinks and smash them, but there are so many places, so many nested loops with db/cache accesses

Glasow: I can see in the network tab the ajax request is receiving the cookie in the response header, but i’m not seeing it in xhr.response, nor do i see it in do***ent.cookie

Merow: Literally 500 lines of code doing not less than 30-40 db accesses, including multiple reads to the same data

Chemell: Yansanmo, Ok and from yesterday, input type=”email” will check format. For this cl*** I can still javascript validate that its not empty right?

Muhlestein: Not empty is required=”required”

Lipinsky: I’m not seeing any cookies being p***ed to the server in any subsequent requests either

Whitset: Would be great if I could ‘mark’ the whole call stack, then add up the times the function call was marked on the stack. Obviously the low level calls would feature higher, same with the top level call, but the intermediate ones would give me an idea of how many times the call is looped over

Ornelaz: There’s console.count

Ornelaz: If thats what you want

Ornelaz: Idk what you really mean though

Lockbaum: The concept is simple: whenever you are on a low level function, you want to know which functions are above it on the call stack

Sarrett: I thought the profiler in chrome did exactly that when viewed bottom up

Keh: Say you could get the function call addresses with something like stack. this would give you a stack or list or whatever with all the return pointers. just foreachi in stack { timescallingi++; }

Ornelaz: You could abuse Error to get the stacktrace and then look at that. i’d just drop a breakpoint there though and skip over the times it gets hit that i dont care about

Rovinsky: The problem is it will be hit millions of times :/. I desperately want to avoid reverse engineering this horrible handmade cache

Seykoski: Did i mention that it mixes the view with logic?

Ornelaz: It’s being hit millions of time and you dont care about most of them?

Wayns: My objective is to compact this millions of calls into less calls

Haygood: I don’t want to optimize the whole code, there is no single big point of failure, simply the fact that queries repeat themselves over and over

Bonaccorso: But there probably are two or three big offenders

Ornelaz: Then you’d find it out pretty quickly with a breakpoint.

Kamphoefner: I’ve never debugged javascript, i wish i knew how to use these tools :p