[WriteLog] RE: Software Memory Leak (maybe!)

[Barry]

I noticed a major slow-down in both Save and (especially) Delete a 
QSO in 10.28 in the 10m contest (SO1R/CW only PII-450, 128 
meg RAM).
Barry W2UP

On 3 Jan 02, at 10:43, Dick Green wrote:

> 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
> 
> _______________________________________________
> WriteLog mailing list
> WriteLog@contesting.com
> http://lists.contesting.com/mailman/listinfo/writelog


--
Barry Kutner, W2UP              Internet: w2up@mindspring.com
Newtown, PA                     Frankford Radio Club