Keohane: K2gremlin: either submit without reloading the page or generate the message on server side for a reloaded page
Weaklend: Second variant is probably better in this case
Sarrett: K2gremlin: normally you’d have the server redirect to a thank you page after receiving the form, no javascript required
Sarrett: K2gremlin: you have to change the fiddle to “no wrap” instead of “onload”
Kakudji: Currently I’m looking at the profile and I have over 50% in program. What does this mean?
Sarrett: K2gremlin: its in the fiddle options, default is “onload”
Natvig: Tcsc: would you mind guiding me a bit when looking at the file? I have some questions about how it is to be interpreted
Ornelaz: Sure, one minute though
Yarberry: Https://www.dropbox.com/s/vcmioh7h8j5e7bs/CPU-20150907T183759.cpuprofile?dl=0
Ornelaz: So, what are your questions?
Ruszkowski: Well, I’m trying to look at the file and find out the following things: 1 how much time is spent on rpcs, 2 how much time is spent on algorithms
Toyne: Http://fiddle.jshell.net/2931d7vt/1/ grrrr. cant get this damn submit button to do what I want lol
Ornelaz: Bfig: what functions do algorithms?
Hollinshead: You didn’t put the return in the inline
Steedman: As far as I understand, about 10% is spent on rpcs, about 50% is spent on client side processing, the rest is spent over other stuff
Rand: K2gremlin, and you can’t put an instruction directly after a return
Kleinknecht: Tcsc: I’m fairly certain there is a ‘renderState’ function that shows most of the problems, visually. There is some other place in the code that I haven’t found yet that precaches everything this function uses
Ornelaz: Bfig: keep in mind that writing your code so that it can be easily profiled and optimized is a thing you often have to take into consideration at design time. barring that, you often need to move code around so that you can get better profiler results.
Gilvin: Yansanmo, Yea I changed it, http://fiddle.jshell.net/2931d7vt/3/
Ornelaz: That said, it looks to me like most of your code is spent sending data via ajax
Cregger: Tcsc: that’s what I would guess from what the code does, but I can’t understand the profiler output
Magwood: K2gremlin, the return in the inline attribute is missing
Ornelaz: There are three views
Abnet: Because 50% of time is spent on program, but what does that even mean? we’re talking about a function that takes roughly 3 minutes to execute
Ornelaz: Program is the browser
Gochanour: Yansanmo, return checkReqFields?
Ornelaz: The browser doing things you’ve told it to do, usually.
Ornelaz: Sometimes unrelated stuff though
Ornelaz: It’s uh, basically noise.
Borneman: Yes, that will tell if the submit should continue true or not false
Drehobl: Idk why but I just can’t wrap my head around javascript. HTML and CSS im getting decent at :/
Ornelaz: You shouldn’t worry about program in the profiler to omuch.
Meinhard: K2gremlin, you are doing javascript, HTML and DOM right now
Pryde: Yansanmo, I thought that was what the return false; did in the javascript
Ornelaz: Most of the things that actually take significant portions of time related to your code it will give you data on
Timmer: Ok. Looking at the database, there clearly is a problem with what information is fetched and how many times. A table with 127 records has 7 million row reads over it.
Fake: But I want to find out where in the js those are being made, because there is a weird and not-so-correct cache layer implemented over the js view
Unruh: The function return a value, but you need to catch it
Bironas: So the reasonable thing would be, as you say, that the database connection is the one taking time, but it would be a ridiculous task to optimize the whole code