Re: Qso counter bug?

[Thomas Beierlein]

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 <address@hidden>:

> Hi Zoli,
> 
> thanks for the test results.
> 
> Am Thu, 7 Nov 2019 19:03:14 +0100
> schrieb Csahok Zoltan <address@hidden>:
> > 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
--