Re: "Checkpointing long" on exit

On Wed, Mar 17, 2021 at 10:41 AM Steve Fiddle <[email protected]>
wrote:

> Some things that we can deduce from observation.
> I'll mostly refer to Peter's timing results from his tests with a 4 GB
> mono WAV file:
> ---
> *With the current release 2.4.2*
> Import from SSD took 53 seconds
> Import from HD took 55 second
>
> In this case, the times are so close that it is clear that the read speed
> is not the limiting factor.
> 4 GB of data is being read from either SSD or hdd in < 1 min.
> The actual read speed for an SSD is typically around 0.5 GB/s.
> The actual read speed for a hdd is typically around 0.1 GB/s.
> (yes I know that these figures are extremely fuzzy)
>
> ---
> *Audacity 3.0.0*
> Import from SSD took 1 min 29 secs
> Import from HD took 1 min 03 secs
> (project on SSD)
>
> We already know that to read 4 GB from either drive is < 1 min.
> We can deduce that there is more overhead when writing to an AUP3 than to
> an AUP. I would expect this because the database has to do a lot more than
> raw data writes.
>
> It's impressive how small the additional overhead appears to be with the
> hdd, but the 63 seconds figure is a bit misleading because the database is
> still chewing and hasn't yet swallowed. This can be seen if you attempt to
> exit Audacity immediately (checkpointing is still running).
>
> Remember that writing the project takes much longer than reading the data
> from the file being imported. In the SSD case, the data is being written
> back to the same disk.
>
> My guess is that the ~90 second SSD figure is probably the actual time to
> write the AUP3 - the data has been read, processed and written into the
> database, but in the case of the hdd, the data has been read, processed
> (waveform calculated) but has NOT yet been completely written to the
> database - perhaps a lot of the data is still in the SSD's cache waiting to
> be written (?)
>
> An interesting experiment would be (unfortunately I do not have the
> necessary hardware to do this):
> Two SSD's and 1 hdd.
> Ideally, all three connected internally.
> AUP3 on an internal SSD.
> Compare speeds importing from the other two drives.
> I would expect that in this case, importing from the second SSD will be
> faster than importing from the hdd, but probably not much faster because
> reading is not the bottleneck.
>
> Does this sound reasonable?
> Anyone with the necessary hardware interested in testing?
>
> I think the valuable takeaway from this is that we need to be careful when
> quoting benchmarks - they may not be what they initially appear to be.
>

The most import aspect here is the UX POV as regard speed - to that end I
retested
*Bug 2457* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2457> - Windows:
WAV Export runs 6 to 7 times slower than on 2.3.3
(especially following the recent Windows build issues on the dev email
thread).

Times for Export of a one-hour stereo 16-bit WAV file

1) Inadvertently I left my Temp files on the onboard HD (left over from
yesterday's tests)
Export to onboard SSD
2.3.3   34 secs
2.4.1   3 mins 21 secs
2.4.2   41 secs
3.0.0   29 secs


Switching my Temp files back to the default onboard SSD

2) Export to SSD
2.3.3   25 secs
2.4.1   3 mins 01 secs
2.4.2   23 secs
3.0.0   26 secs

3) Export to onboard HD
2.3.3   27 secs
2.4.1   2 mins 59 secs
2.4.2   25 secs
3.0.0   25 secs

4) Incidentally the times to generate the Chirp were
2.3.3   19 secs
2.4.1   17 secs
2.4.2   17 secs
3.0.0   17 secs

This tells me
a) Bug 2457 remains fixed for 3.0.0
b) performance (in this regard) has not deteriorated in the 2.x to 3.x
transition

Nut my earlier intensive speed testing with data I/O and EGATS  indicates
that
to be the case.

Peter.





> Steve
>
>
>
> On Wed, 17 Mar 2021 at 09:53, Peter Sampson <
> [email protected]> wrote:
>
>>
>>
>> On Tue, Mar 16, 2021 at 9:54 PM Leland <[email protected]> wrote:
>>
>>> Something that “may” help us understand what’s going on:
>>>
>>>
>>>
>>>    1. Windows menu
>>>    2. Type in “Resource Monitor” in the search box and hit enter
>>>    3. Select the “Disk” tab
>>>
>>>
>>>
>>> Watch the Audacity disk activity between steps.  Allowing Audacity to
>>> “settle” will give you stable timings.  BUT, that’s not realistic timings
>>> since folks aren’t going to sit and wait for Audacity to settle like that.
>>> This is just to help visualize what might be contributing to the various
>>> oddball timing results.
>>>
>>
>> Well I've tried that - but it doesn't make much sense to me, I can't tell
>> what's going on.
>>
>> This is really the province of gray-box testing - and I'm a pure
>> white-boxer.   ;-))
>>
>> Peter.
>>
>>
>>
>>>
>>> *From:* Peter Sampson <[email protected]>
>>> *Sent:* Tuesday, March 16, 2021 11:30 AM
>>> *To:* Devel <[email protected]>; Peter Sampson <
>>> [email protected]>
>>> *Subject:* Re: [Audacity-devel] "Checkpointing long" on exit
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 16, 2021 at 4:16 PM Cliff <[email protected]> wrote:
>>>
>>> If I can inject here, the speed of the external SSD will depend on the
>>> type of bus it is connected to. The USB3, which is the normally used way,
>>> can be slower than the internal bus which may be much faster so the
>>> internal disk could have better throughput in some cases. For maximum speed
>>> the SSD should be the internal drive. Just a thought when doing a
>>> comparison.
>>>
>>>
>>>
>>> My 256 SSD and my 1TB HD are *both* internal drives.
>>>
>>> The SSD is my system drive and my main work drive.
>>>
>>>
>>>
>>>
>>>
>>> So I id some comparison testing - using a one-hour stereo 16-but WAV
>>>
>>>
>>>
>>> *1) Temp files on SSD (default scenario)*
>>>
>>> 1.1) Export to SSD  23 secs
>>>
>>> 1.2) Import from SSD 31 secs
>>>
>>> 1.3) Export to HD  24 secs
>>>
>>> 1.4) Import from HD 24 secs
>>>
>>>
>>>
>>> *2) Temp files on HD *
>>>
>>> 2.1) Export to SSD  22 secs
>>>
>>> 2.2) Import from SSD* 1 min 57 secs*
>>>
>>> 2.3) Export to HD  25 secs
>>>
>>> 2.4) Import from HD 22 secs
>>>
>>>
>>>
>>> So 2.2 looks *seriously* awry at more than 5 times longer - and I have
>>> no idea why   :-//
>>>
>>>
>>>
>>> But even 1.2 looks iffy compared with 1.4 at a 30% increase.
>>>
>>>
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cliff
>>>
>>>
>>>
>>> On Mar 16, 2021, at 10:44, Peter Sampson <[email protected]>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>

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