On 14/11/2018 13:57, DG2YCB, Uwe wrote:
Status now (= only 4-6 weeks from deadline when ALL users in the world
have to switch to v2.0.0) is that (A) most of the new highlighting
ideas are not operational, and (B) the ones which worked very well
until in v1.9.1 are now at least partly broken. I am really
disappointed about that! (I’ve personally been in charge of dozens of
development projects, so I am fully aware of all the threats and
drawbacks. But here we have a quite simple decision tree. It should be
not that difficult to bring it to work.)
Hi Uwe,
the decode highlighting has been virtually re-written, this is due to
the prior implementation not being suitable for scaling up to add the
new categories. Rest assured that your worries about performance and
impact on decoding speed are absolutely topmost with the new
implementation. I expect the impact of worked before computation on
decode printing speed to be negligible, this is due to a design that
builds optimally efficient in-memory indexes of the various categories
that can be looked up with minimum CPU cycles. Of course there is no
free lunch and there must be a cost somewhere for this high performance,
that lies in updating the indexes with new entries. The update cost of
adding new index entries for a new logging event is low and carried out
without any impact on decoding since it is done at "user" speed. The
initial cost of build the indexes is paid at application start up and
there may be a point at which the size of the user's ADIF log becomes an
issue, if that becomes troublesome it is not hard to offload that
initial load to a separate CPU thread with decode highlighting disabled
for, perhaps, the first decode period. Another cost is the memory
footprint of the lookup set (there is only one table), this will be
proportional to the users log file size to an extent, there are
mitigating strategies available if this becomes an issue e.g. currently
there is the possibility of listing QSO details of worked before matches
and this may prove to be unnecessary or perhaps could be offloaded from
RAM to a database table or simply not stored.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
