Hi Tom, Made a quick test with the slowest machine that I use, a Pentium M 1.7GHz. Execution of readcalls() took about 150 ms per 1k QSOs (data are below). The code scales mostly linearly except dupe checking that is using a slow linear search. Latter makes it O(N^2) but its contribution is quite small: for 5k removing dupe checking reduced execution time to ~600 ms only. Probably not worth changing it to a hash lookup at the moment. Most of the time (~2/3) is spent figuring out DXCC info in getctydata().
Considering that typical Q counts are around or less than 1k we can conclude that re-reading takes ~100 ms or less. Such a delay is completely bearable for a deletion or other operations (e.g. log editing). One thing I noticed is that upper bounds of various arrays are not checked, the program crashes simply with segfault. It's prio3 but should be addressed later. 73, Zoli # # Intel(R) Pentium(R) M processor 1.70GHz # # Q ms 5000 740 4000 580 3000 410 2000 280 1000 130 800 110 500 70 300 45 On Thu, Nov 07, 2019 at 07:54:32AM +0100, Thomas Beierlein wrote: > Rereading the problem and my own answer it seems I got it total wrong. > Sorry for that (Lessons learned: DO not answer mails if you are not > fully awake). > > Zoli is right, there are two bugs to fix which should be done before > release of 1.4.0 version. > > Anyway we should test how much time a automatic rescore after delete > takes and if we can use that now, given the actual speed of modern > computers. > > 73, de Tom > >
