Hi Robert, On Sun, 30 Apr 2023 at 03:07, Robert.Helling <[email protected]> wrote:
> > I don't want to spam everybody with my questions, so will send it directly > to you. The question is rather lengthy cause it require long explanation of > how did I get there. > > > I understand your intention but please really use the mailing list for > anything that does not discuss personal matters: Not only possibly more > people can help with an answer (and others typically have means to ignore > threads they are not interested in) but also there is the archive and > information can be found there in the future. > > Ok, I see. Will use mailing list from this point on. > > > Anyway. Do you have any reasons to keep that cache around, let alone to > use it for data transfer into planner? Can I just get rid of it and pass > all data through one structure? > > > See, it is a cache. Like pretty much all caches, technically, you can get > rid of it. But the price is that things get slower as they have to be > recalculated. > We just don't have to expose this cache outside, we have to rethink the structure and prevent this constant copying of data. We'll actually win in computation this way. Let's not talk about speed at the moment, cause my question is more architectural and high level. We'll make it run faster, that's for sure. To know tissue loadings in a dive, you have to know what the tissue > loadings are at the beginning of a dive from previous dives. This is > determined by going back in time through the divelist (until you hit a 48 > hour surface interval) and sum up the deco data for those dives. This is > what init_decompression() does. Depending on how many dives this involves > this can be an expensive calculation. > Ohh. I see. So, this juggling around with cache double pointers is just a very hacky way to save on running init_decompression and to pass it from one variation to another, right? Ok, I'll clear that up. ........ > Does this help? > > Yeah, thank you for prompt response. -- Thanks. Vlad A.
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
