 |
 |
Dear Gary, Comments below: On Fri, 17 Aug 2007, Gary S. Thompson wrote: > Wayne Boucher wrote: > > >Hello, > > > >On the first point, if you have a lot of peaks (in total) then Python will > >eventually become slow. (That is the one part of the data model which has > >this problem.) So that in itself could be causing problems. But of > >course if you have large numbers of spectra then the program also has to > >load all the data from disk for contouring, which takes time. It's a hard > >problem to know what to do (except to throw more memory / CPU at it). > > > > > > Does analysis load the whole data model into memory each time it starts? > could it do some lazy loading e.g. load proxies for top level objects > such as spectra peak lists which provide basic information etc until > they are used? We do do lazy loading, but the granularity is coarser - we load the entire NMR project at once for instance. The problem is that there are so many crosslinks, peaks are linked to lots of things including resonances, and resonances are linked to everything. Lazy loading is a lot easier to handle if the blocks you are loading are not too tightly linked to the rest. We did split constraint lists off, for instance. > >If you take that one line out then the peak cloning with assignments is > >around 60 per second. (Obviously all these timings are on his computer so > >the relative timings are what to pay attention to.) So if you want to > >play slightly dangerously you could comment out that line. It's a hard > >one to call that one. > > > > > > One question here is do you need validity checks during a clone > operation? surely the peak list you start with should be valid anyway... > so as long as you make a faithful copy (i.e. there isn't a bug) the > resulting peak list should also be valid. So would this change really > be dangerous? The clone operation uses 'copySubTree'. This a hightly complex generic function that bypasses the API and its safety checks, and the risks of problems are higher here. copySubTree has been in use for a while, but even so it might be wise to keep checking. It is a trade-off between speed and safety. We will have a look (remind us if we forget), but the new version coming up is different and should be faster at a number of things. It does not make sense to optimise for speed before we complete the change-over. Yours, Rasmus