Hi, > On 20. Sep 2017, at 15:01, Stefan Fuchs <sfu...@gmx.de> wrote: > > Maybe we should indeed disable most of the planner UI elements while the > calculations are performed and enable them again after they are finished. I > would love to test this but once again recognized that I have almost no > object oriented programming skills at all... :-(
no, the planning should happen in a background thread. During my vacation, I also tried to implement that. The problem is that it steps on its own feet, it is not reentrant: The problem arises when two instances of the planner run in parallel (triggered by two updates in the UI or, as complained about earlier, since each UI update seems to run the planner three times. Even with a huge lock, it only produced garbage. Plus, it shouldn’t be a lock, each new invocation of a planner thread should kill all previous ones. If you want to have a look, I just pushed my branch planner_in_background to my GitHub repository. Feel free to improve that. Probably you would have to find more state variables that should exists not just once but on a per thread basis. Yesterday, I sent a pull request for a switch to turn of the computations of the variations. With that switch set to off, do you still think the responsiveness of the planner is worse than before? In that case, a bit more profiling work could improve that situation. A bit of background: Before the summer, to determine the length of a deco stop, the planner would try to ascend. If that was not possible, it would stop for a minute and repeat. So, the number of attempted ascents would be proportional to the stop length. With the new code, it does a binary search: It makes a guess for the stop length (based on the previous stop), if that is sufficient for a clear ceiling, it halves the interval between what is known to be too short of a stop, if it is too short it doubles the time. So the strategy is a bit more complicated and has a but more overhead but the number of attempts should only scale logarithmically with the stop length. For short deco, this might be worse than what we previously did, but in particular for long deco this is much much faster (and I did it since for the variations calculation I wanted a 1 second resolution rather than one minute. The difference now are six more iterations rather than 60 times more!). The price to pay is also in the fact that previously, we could cache the Buehlmann factors for one minute while now we need them for many different time intervals. But we also cache those now (at the expense of memory) so that factor shouldn’t be too bad. Best Robert
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
