Re: Qso counter bug?

[Csahok Zoltan]

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