CPU hogging in the current master

[Anton Lundin]

On 24 September, 2013 - Dirk Hohndel wrote:

> On Tue, 2013-09-24 at 13:04 +0300, Lubomir I. Ivanov wrote:
> > i've noticed that particular dives in the Qt divelist make the
> > application non-responsive for n seconds.
> > 
> > test case for a couple of builds - Qt (master) and GTK (binary from
> > 12.may.2013):
> > - disable all extra profile plot settings
> > - import all test dives
> > - select dive #20 (20th test dive...)
> > - measure render time, roughly
> > 
> > with this old GTK build it takes milliseconds, with Qt it takes >5 seconds.
> > 
> > after some testing i've narrowed down the cause to be in the "backend"...
> > profile.c: calculate_deco_information()
> > while(next_stop >= 0) {
> > ...
> > 
> > where 'next_stop' seems to update thousand of times between 3000 and 0
> > for this dive.
> 
> This is the TTS (time to surface) calculation - and reading the code I'm
> a bit confused by what it is trying to do.
> 

So, i have had a look at the code and the test case and have some
explanation.

For every sample it calculates the next deco stop and then the whole
deco profile after that, to produce a tts. In that dive, it maxes out at
a TTS to about 1020 minutes (17h deco) before you can break the surface.
That means that its quite a long deco calculation, for every sample.
The code calculates the tts in 10s steps (time_stepsize).

Shure, we should have a option for disabling the NDL/TTS/deco-stop
calculations and some options to adjust the constants we are using in
that code. The planner was under way at that time and i thought that it
might introduce such settings to use.


> > it seems that this portion of code was written by Anton Lundin in
> > july, so i've CCed him in this email.
> > 
> > git blame profile.c -L 1091,1107
> > 35356e36 (Anton Lundin 2013-07-05 15:19:41 +0200 1091)
> > 
> > could this algorithm be somehow improved?
> 
> Clearly July wasn't my best month as maintainer... I should have
> scrutinized this a bit more...
> 
> Let's see what Anton has to say, otherwise I can look at reimplementing
> this. It should be pretty easy to simply cache the values instead of
> constantly walking forward and backward.

It should be possible to do something more intelligent, but i thought
that it was better to get something that worked and might be a bit slow
to start with =)

//Anton

-- 
Anton Lundin	+46702-161604