Hi all, I just pushed two commits to fix the problems mentioned in issue #138 on github.
Please test and report back. If the problems are solved I will release TLf-1.4.0 with that fixes. 73, de Tom Am Thu, 7 Nov 2019 20:05:39 +0100 schrieb Thomas Beierlein <dl1...@darc.de>: > Hi Zoli, > > thanks for the test results. > > Am Thu, 7 Nov 2019 19:03:14 +0100 > schrieb Csahok Zoltan <ha5...@freemail.hu>: > > 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(). > > Ok. That means we can just 'rescore' after each deleted QSO. That > would be good as we can correct the wrong counts of QSO per band > but have no chance to make any changes to multis or similar undone. > That will always need a complete rescore as long as we stay with the > actual data implementation. > > > 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). > > > Yes. But I think we should delay the switch to always rescoring > after delete to the next TLF revision to get some room for tests. At > the moment I suggest that we just fix the wrong startup counts and > make a note in the ToDo file. > I am sure there will be some more problems with 1.4.0 and we will need > a bugfix version 1.4.1 in next weeks anyway. > > > > 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. > > I tried to move the critical arrays to GLIBs growing array in last > years but it seems there are some missing. Do you have an idea which > ones were the problem? > > 73, de Tom DL1JBE > > > 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 > > > > > > > > > -- "Do what is needful!" Ursula LeGuin: Earthsea --
