So the reasonable thing.

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://

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:// 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,

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