Re: Several questions/comments
|
I don't know how Log4OM behaves with such a volume, but I know how QLog behaves -?it is not fast enough for comfortable work. Based on your emails, I tried to look into areas where improvements could be made, and I found a few. So far, I see improvements in these areas: - Backup - its timing will be adjusted so that backups occur at a more 'reasonable' frequency.
- Performance improvement when manually inserting QSOs or inserting via WSJTX.
- Unfortunately, the time it takes to show all QSOs in the main window is due to a previously reported issue where CTRL+A didn't work to select all QSOs. I would also like to make some changes here. I've decided to return to partially loading visible QSOs and disable CTRL+A for selecting all QSOs. Hopefully, this will lead to the expected performance improvement in display.
Where I still don't see improvements is in importing via ADI/ADX. I've rewritten this part of the code several times, but the performance is still not sufficient. Regards Ladislav
?t 12. 9. 2024 v?3:44 odes¨ªlatel Phill Hardstaff via <phill= [email protected]> napsal:
I'm at 70K QSO nearly and it's still going OK, I would venture to say it works better than Log4OM with the same number of QSO. And Log4OM using the same backend. HRD was a dog even at 50K QSO. The limiting the rows displayed is a good suggestion Michael, am going to try that. Having said that though some loggers by default set some limit on rows displayed with a little widget that you can type a number into to change it. Like 1000 for last 1000 records.
?
Keep up the good work Ladislav.
?
73 Phill C21TS / FK1TS / 3D2TS
|
