I've made some general comments about memory leaks in another email, but
what about the performance problem that was reported? It's not at all clear
to me what the problem is or what's causing it. All I can say is that
there's no real evidence to support the memory leak theory.
I've seen different symptoms reported that could indicate more than one
problem or no problem at all. During the fall contest season, several users
complained that the Save operation was taking unusually long for large logs
under version 10.28D. Recently, someone reported slow operation with 10.29E.
As I recall, that report did not specify exactly which Writelog operations
were slow. Was it general operations or Save? What was the automatic Save
setting (e.g., was it set to save on *every* new record?)
If a particular user experienced a general performance problem, then I would
suspect that the user's computer doesn't have enough RAM. If it's the Save
operation, then I would question whether Wayne has modified the Save
algorithm in version 10.28D or later. There was a change about a year ago or
so that greatly speeded up the Save operation. Have you made another change
Wayne?
I used 20.28D in CQWW CW for about 2200 QSOs with no problems (600 MHz,
384Mb, Win2K.) I've used previous versions up to about 3500 Qs with no
problems. However, as the log gets larger, the Save does take a little
longer. Not enough to bother me, though. Back before Wayne changed the Save
algorithm, the delay was bad enough to significantly impact my rate late in
the contest. Now it's OK. I think K5ZD reported some slow Saves with 3K+
QSOs in CQWW CW this year. Randy -- was it slower than your 2000 4K+ QSO
effort? Did you change computers?
Currently, Writelog immediately writes each new log record to the journal
file, but only updates the main log file when a manual or automatic Save is
done. The entire log file is rewritten for each Save, which is why it takes
so long to save a large log file. One way around this would be to use record
I/O to update individual log records. That would probably require
integration of an open-source database manager, which would be a *lot* of
work for Wayne to implement.
A much easier option that requires no work for Wayne would be to turn off
Writelog's Auto Save option (set AutoSaveCount=-1 in the ini file.) This
will cause Writelog to delay writing the log file until you manually save it
or exit the program (when you quit, Writelog prompts you to save the log
file if you haven't done so.) Since all updates are written to the journal
file, this should be safe even if the program or computer crashes. Even if
you tell Writelog not to save the log file when you exit, the updates are
still in the journal file and Writelog will prompt you to incorporate them
when the log file is reopened. Seems to me that this is a perfectly safe way
to run Writelog -- no less safe than doing the Save. In either case, the
updates are stored in only one file. If you really want to be safe, you can
network another computer to act as a backup for the log -- I use my notebook
computer for that. If you don't have a second computer, you can periodically
save the log file and copy it to a backup location, such as a floppy (just
keep a copy of Windows Explorer open -- you won't get a sharing violation
when you copy the log file because Writelog doesn't keep it open.)
73, Dick WC1M
|