Re: "Checkpointing long" on exit

On Tue, Mar 16, 2021 at 3:15 PM Steve Fiddle <[email protected]>
wrote:

>
>
> On Tue, 16 Mar 2021 at 14:22, Leland <[email protected]> wrote:
>
>> > -----Original Message-----
>> > From: Steve Fiddle <[email protected]>
>> > Sent: Tuesday, March 16, 2021 8:25 AM
>> > To: Audacity-Devel list <[email protected]>
>> > Subject: [Audacity-devel] "Checkpointing long" on exit
>> >
>> > Why is this happening?
>> >
>> > Importing large WAV from hdd:
>> > 1. Launch Audacity
>> > 2. Drag and drop large WAV file (2.4 GB) from hdd into Audacity.
>> > Import takes about 45 seconds.
>> > 3. Exit Audacity
>> > 3.1. "Save project before closing?" -> No
>> > 3.2 "Checkpointing long" dialog opens and may take 30 seconds before
>> > Audacity closes.
>> >
>> > Why is Audacity doing "checkpointing"?  What is it actually doing?
>> >
>> > If I wait a couple of minutes after the file has fully imported before
>> exit,
>> > Audacity closes immediately. Does this mean that Audacity is actually
>> doing
>> > part of the import process in the background after the waveform has
>> > appeared?
>> >
>> > Importing from SSD:
>> > 1. Launch Audacity
>> > 2. Drag and drop large WAV file (2.4 GB) from SSD into Audacity.
>> > Import is MUCH slower (around 1 minute 30) ???
>> > 3. Exit Audacity
>> > 3.1. "Save project before closing?" -> No
>> > 3.2 Audacity closes immediately.
>> >
>> > Why does import from SSD take twice as long as from a much slower hdd?
>> >
>>
>> Checkpointing is done in a separate thread and when a database is closed,
>> all checkpoints must complete before Audacity can continue.  In both of
>> your cases, the checkpointing should be started while the file is still
>> being imported.  But, in your first case, the checkpoints take longer to
>> complete so there's more left to do when the database is closed at Audacity
>> shutdown.  In your SSD test, the checkpoints seem to be finishing during
>> the import and not delayed to database close.
>>
>> Well, that's my first guess anyway.  A quick review of the code does seem
>> to prove the theory, but reality may vary slightly.  😊
>>
>
> That's pretty much what I guessed, but it doesn't explain why importing
> from a fast SSD is much slower to display the waveform than when importing
> from a much slower hdd (as both Peter and I have observed and measured).
>

When I was (re)testing 3.0.0 versus 2.4.2 last week I was using a 30 minute
stereo WAV 24-bit 4GB
All tests on SSD at that time.

my import times were pretty similar for both versions - no great variances.
My test macro opens a test project, exports and then re-imports - these are
v3.0.0 times
to import, and all acceptable times I thought:
a) WAV 11.9 secs
b) MP3  7.7 secs
c) Ogg 4.3  secs
d) m4a/aac 5.0 secs
e) flac 4.2 secs

Perhaps more importantly I have been using the various alphas and latterly
RCs
as my production system for several months now (and as you know I work with
2-3 hour stereo shows) and IRL use I have never thought "Boy, that's taking
too long"

I can do some more tests of SSD versus HD both Import and Export if
folk think that might be worthwhile ?


> @ Peter, which drive is your Audacity temp folder on?
>

On the SSD of course.

I can try putting my temp files on the 1TB HD  foe SSD/ND Import/Export
comparisons if folk
think that would be a useful test ?

Peter.




> @ devel, could it be anything to do with the file being read and the
> project being written to being on the same drive?
>

> Steve
>
>
>>
>>
>>
>>
>>
>> _______________________________________________
>> audacity-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
> _______________________________________________
> audacity-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

_______________________________________________
audacity-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/audacity-devel