[PATCH] Stop doing the (very expensive) pow() calculation pointlessly

[Dirk Hohndel]

On Jan 19, 2014, at 1:03 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:

> On Sun, Jan 19, 2014 at 12:42 PM, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>> The result of this patch is this:
>> http://wstaw.org/m/2014/01/19/plasma-desktopujz493.png
>> it still looks like it deserves some kind of special treatment, but it's way
>> faster now.
> 
> So you seem to have TTS enabled (time-to-surface).
> 
> What do you use as a test-case? Because there are a few tests in there
> that generate horrible TTS loads because they are actually bad dives
> with tons of deco, and then the TTS calculations just explode.

I believe Tomaz usually uses my dives and in the snapshot that he has the lovely dive 222 is the first dive that is shown - which creates quite some deco calculations :-)

> Anyway, for the TTS calculations, try this trivial patch that makes
> the TTS code use a 1-minute step-size rather than calculate things at
> a 10s interval.
> 
> There are other things we could do too. For example, in
> calculate_deco_information() we actually do the deco calculations by
> adding a segment for every *second* (see the loop that goes like
> 
>                for (j = t0+1; j <= t1; j++) {
>                        int depth = interpolate(entry[-1].depth,
> entry[0].depth, j - t0, t1 - t0);
>                        double min_pressure =
> add_segment(depth_to_mbar(depth, dive) / 1000.0,
> 
> &dive->cylinder[entry->cylinderindex].gasmix, 1, entry->po2 * 1000,
> dive);
>                        tissue_tolerance = min_pressure;
>                }
> 
> and that whole loop is likely pointless. We could just do that one
> plot-entry at a time (we do plot entries generally at a minumum of
> 10-second intervals, depending on sample intervals etc they can be
> more common).
> 
> The second patch has that "simplify calculate_deco_information" part
> in it too (in *addition* to the 60s TTS interval change that is in the
> first one).
> 
> I bet the first one is the one that makes more of a difference, but
> you can try to see if the second patch improves things further.

I would like to run some comparisons - my gut feeling is that the results with the second patch will be by and large the same as with the current code… so maybe we should just switch to that somewhat coarser approach.

/D