tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Qso counter bug?


From: Thomas Beierlein
Subject: Re: Qso counter bug?
Date: Thu, 7 Nov 2019 20:05:39 +0100

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
--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]