loader image too easily missed

[arigo]

http://vmprof.com/static/images/loader.gif is too easily missed when we click somewhere in the page, and it's the only feedback that we actually clicked and have to wait. Worse, it might be completely off the page if we scroll down before clicking.

[planrich]

I made the spinner bigger and centered it. It is also fixed now, meaning if you scrolled down you will still see the spinner.

[fijal]

given the long wait times it would be really lovely if we could get an indication of how long it would take. Also the spinning wheel does not stop spinning if something crashes or timeouts, so it's of no indication whatsoevver

[fijal]

This is a good example - server crashed, but the wheel is endlessly spinnign without any notification. Those progress bars are as good as not existing :/

[planrich]

I expanded the angular app to display error messages. If for example an exception is thrown while processing the trace, and it has an error message, it will now be displayed, and the spinner stops. I'll redeploy tonight, let's see if that is better

[fijal]

any chance we can get an actual progress bar with some indication how long it might take?

[planrich]

Advanced. What is unclear to me is how to deliver the progress over HTTP. We would need some kind of streaming http request (web socket?). Is that supported on IE?

The trace tree is cached in memory. Assuming that the parsing takes the most time, this is only needed the first time. We could get around that by loading the trace tree into the cache as soon as the log file is sent to vmprof.com, not when it is requested.

Other than that, the requests should only transform parts of the tree to json. Parsing is required only once.

@fijal can you tell me what action takes the most time? the first load of the page? clicking traces? the latter would only need some refactoring in JS

[jonashaag]

What took the most time for us was loading the huge profile JSON blob from the SQL database. Not sure if you're having the same problem. My guess is that it's not a download speed problem, but a server performance one. (This is of course easily checked with Chrome Web Debugger etc.)

Pure download progress can be easily achieved with the progress event of XmlHttpRequest, see https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest#Monitoring_progress