Split from http://forum.audacityteam.org/viewtopic.php?p=295956#p295956
I don’t know what your usual workflow is. How many Undo levels do you have? Are the levels of large data size, or small, like adding a label?
Does discarding maximum levels before quitting Audacity make the History window disappear more quickly?
I recall the History was not showing size of data correctly a few versions ago and fixes were made for that.
Gale
I typically accumulate hundreds of undo levels before I discard any, which I usually do only if I’m running low on free disk space. Currently I’m not (free >14 GB). Most of the levels are 0 bytes, for labels. Those that aren’t may add up to a significant percentage of the length of the project. I make the 1st label track, RTags, while recording on the laptop. I seldom edit on the laptop (screen’s too small). My first step in editing is to make another label track, Sections, and label each section. This is the prototype for all label tracks for export. It also contains a tag for each section that will be converted to Mono, so the file names contain the tags and I can convert them later. A third label track, TTags, is for documenting every effect I’ve applied, and save the pertinent data for every region where I’ve checked the noise spectrum. The first thing I do before operating on any audio is High-pass filter the whole recording (20 Hz, 6 dB/octave), so if I’m in the first editing session for the project that step will always be full length. There is always one very long portion that will be Mono, so I convert that one before doing any filtering on it. I generally apply filters to the rest of the sections while they’re still in the Stereo track because some filters cross section boundaries. The finished project has 1 Stereo track and 1 Mono track, plus TTags, RTags, Sections, and another label track for each export.
I assume you meant the Audacity window “skeleton”, as I called it. Guess I’ll have to try it and see. I did notice that that long delay to display the History window only happens once. After that, it displays reasonably promptly. Similar behavior the first time I create a label.
[EDIT]
Tried it… There were 190 undo levels. It took about 30 sec to undo 180 levels and then about 8 sec to close Audacity. So my answer is Yes, the window “skeleton” disappears quite a lot faster after undoing history.
[/EDIT]
This reminds me - Not long ago, History showed the gain value for Amplify. I kinda miss that. I apply Fade by dB after I finish all the level adjustments, so it’s rather useful to have the correct gain values logged in my TTags. Unfortunately, I sometimes forget what the gain was by the time Amplify finishes on a long section, and I’ve gotten used to checking History to find it. I think Amplify is the only effect that can’t tell me the last parameter(s) I used.
When is the slowness opening History occurring? If you launch Audacity and open History, how long do you wait? If you perform 200 actions that are recorded in History without having History open and then open it, how long do you wait?
I don’t think History was slow in recent previous versions of Audacity. Have you noticed History slowing up in 2.1.2 or 2.1.1?
Audacity itself will be slow if there are many tracks or long tracks, so it can be hard to distinguish that effect from Undo slowness.
I don’t think any of the built-in effects that can show their parameters in History now do so. This went wrong in 2.1.1.
Gale
Guess I should have posted anew instead of editing my old post. Deleting 180 levels of History took about 30 seconds. The History window is slow only the first time I open it. It could be that back when Amplify showed its Gain value there I opened it more often and so didn’t notice how long it could take in previous versions. Next session I’ll try opening it right after launching and again right after loading the project and then see how long it takes later on.
I recall recently (with 2.1.2) undoing several levels via History, having not previously opened the History window. Disregarding the time to open the window, it seemed the individual undo’s took much longer than they used to (which was almost no time). Later on in the same project, undo’s went faster.
I believe Windows File Indexing can be a factor if files are accessed more than once. The first time I open a project that I’ve transferred from the laptop it takes quite a while to load the project. Subsequent times, the same project opens in a second or two, and it’s not due to any huge amount of deletion during the editing session. This is true even if the computer has been shut down between sessions, and it applies to all Audacity versions.
I did the experiment I described in my previous post, and it seems doing the experiment changes the result:
launch Audacity 2.1.2
History: immediate
Load project (work in progress from yesterday): 1 sec
History: skeleton immediately appears, then 90 sec. to fill window (size=2.3 GB)
Close Audacity: immediate
Launch Audacity 2.1.1 [EDITED, was “2.1.0”]
History: immediate (new proj 0 bytes)
Load project: < 1 sec
History: 1 sec (2.3 GB)
Close Audacity: immediate
Launch 2.1.2
Load project: 1 sec
History: 1 sec (2.3 GB)
2.3 GB matches size of the _data folder.
Note the difference between the 1st time 2.1.2 displayed History with the project loaded (90 sec) and all other times, with both 2.1.1 and 2.1.2 (1 sec). Windows File Indexing could make a difference of this magnitude, but I don’t see how that would get involved here.
[edited Jan 15: I had written “2.1.0”, but my shortcut was pointing to version 2.1.1 so that’s what I was using for comparison]
I think the indexer runs when creating, modifying or deleting a file in an indexed location. So I’m not sure indexing is the explanation unless you move the project just before opening it.
I rarely search inside files and use a fast Master File Table search for file names, so the Indexer is a wasteful performance hit for me and I have indexing off on all my drives.
If you have a Solid State Drive you should think of the impact of Indexing on the SDD’s lifespan. Move the Search Index from the Solid State Drive to a Hard Disk Drive if you have a hard drive as well.
Gale
So what happens if you move in another large project from your laptop, but open it first in 2.1.1 then repeat the above tests?
Do you have older Audacity versions you can test with, say 2.0.6 or 2.1.0? You can get them here: http://www.oldfoss.com/Audacity.html.
Windows Prefetch may cause Audacity to launch faster next time due to using RAM rather than disk, but I don’t “think” that caches data from documents the app uses, just data and DLL’s the app needs to launch.
Gale
Will find out next week…
Yes, I have 2.0.5. Do you have a preference whether to use 2.1.1 or 2.0.5 for the test above? For the test, I’ve been launching Audacity and then opening the project, rather than passing the .aup file to Audacity.exe. That way I can separate the launch time from the project load time. I think 2.1.2 RC2 is currently the default if I just double-click on an .aup file, but y’know, I’m starting to lose track…
BTW, I found out why I’d been having problems with multiple versions (this goes back in history and has no relevance to this topic). I’d been using folder names with dots in them in ‘Program Files (x86)’. Dots are allowed in folder names, but inside this folder they cause the offending folder to be skipped in the “open with” list. In general, having dots in folder names or possibly extra dots in file names causes Windows to accumulate lists of unassigned file types in the registry. The project cataloging convention I’ve been using requires them for my batch scripts to work, and I have years of archives to rename (I archive whole projects) were I to change that convention now, so I just run CCleaner once in a while to clean up after myself.
The project opens quickly even if the computer has been turned off since it was last opened, so it can’t be due to caching in RAM. It might, however, affect the test results I reported because, according to the Wikipedia article, it looks like anything the app reads in the 1st 10 seconds may get cached.
I have only 4GB of RAM, so I’d squeeze out most of the cached data before I finished editing. Resource Monitor says I’m using 50% of my RAM right now with Audacity, Notepad and Firefox running. I haven’t applied effects to more than a few MB of audio since I opened the project.
I don’t have an SSD.
The History changes I recall testing were released in 2.1.1, so you could perhaps test 2.1.1 first.
Gale
So it will be 2.1.1, then 2.1.2, then 2.1.1, right? (i.e., just the reverse of what I did on 1/14)
Or did you want a comparison between 2.1.1 and 2.0.5, i.e., 2.0.5, then 2.1.1, then 2.0.5? (You did ask whether I had 2.0.6 or 2.1.0)
If using 2.1.1 first is consistently quick to open history after opening the large project, there is no need to test older Audacity versions.
If 2.1.1 first is slow just like 2.1.2 first is slow, then you could if you want try older Audacity versions first.
Gale
Didn’t have to wait till next week - I found a few old projects on the hard drive. For these experiments, I didn’t launch Audacity and then browse for the project, I just dragged the .aup file to Audacity to launch & load. I tried 2.0.3, 2.1.1, and 2.1.2, but it appeared the “slow history” issue is common to 2.1.1 and 2.1.2 so I started comparing 2.1.1 with 2.0.3.
Project 2016.01.13PM (possibility of having opened this project previously, it was on the HD but I hadn’t started working on it):
Launch/load 2.1.1 4 sec
History 18 sec 1.0 GB
Close immediate
Launch/Load 2.1.2 5 sec
History 1 sec 1.0 GB
Close immediate
==============================
Project 2010.10.17PM (from HD):
Launch/Load 2.1.1: 4 sec
History 23 sec 1.7 GB
Close immediate
Launch/Load 2.1.2: 3 sec
History 1 sec 1.7 GB
Close immediate
==============================
Project 2010.11.14AM (from HD):
Launch/Load 2.0.3: 35 sec after subtracting time that error dialog (ffmpeg config) was displayed.
History immediate 1.9 GB
Close immediate
Load/Launch 2.1.1 3 sec
History 1 sec 1.9 GB
Close immediate
=============================
Project 2011.02.27AM (from HD, had opened project on 4/4/2015, the date from export files):
Load/Launch 2.1.1: 3 sec
History 24 sec 1.6 GB
Close immediate
Load/Launch 2.0.3: 3 sec after subtracting time error dialog (ffmpeg config) was displayed
History immediate 1.6 GB
Close immediate
Load/Launch 2.1.1 3 sec
History 1 sec 1.6GB
Close immediate
So History display after loading the project on 2.0.3 is pretty quick regardless of whether any of these Audacity versions has displayed it previously. It’s very slow on 2.1.1 and 2.1.2 unless it has been displayed previously by some version of Audacity.
Thanks, Dick.
Is there a comparable problem closing a History window containing a few hundred entries in 2.1.1/2.1.2 but not 2.0.3?
If so, is that problem only when closing an open History window when closing the project, or do you also see it when closing History while the project is open?
Gale
I just started editing a project on my Windows 7 laptop running 2.1.0. I’d recorded it yesterday on this system and saved it. Today when I opened it, it took 54 sec to load. I displayed History after load, and it displayed immediately (2.7 GB, which matches size of the _data folder). I’m fairly certain that I had not displayed History yesterday. The only things I’d done yesterday after recording and saving project were adding labels and exporting selected audio before closing Audacity.
Since I use the Windows 7 laptop for recording church services and rarely for editing, I update it only to fix problems but would certainly install other versions on it for test purposes if requested.
I hardly ever shut down Windows on the laptop - I use Hibernate instead so I can get it running quickly when I get to church. I even start Audacity before putting in Hibernate so it’s ready to go.
Should I put 2.1.0 back on the Vista system and try using it instead of 2.0.3 for the old version comparison?
I don’t recall any issue of History being slow to close even with a long list, but there was certainly an issue with closing Audacity 2.1.2. I’ve used 2.1.1 very little except for these tests because the ‘B’ and ‘C’ commands didn’t work on my Vista system (never found out why). I doubt I’ve ever closed Audacity with the History window open. Since the slowness closing Audacity didn’t happen if History had been displayed, might it be useful to try closing Audacity with History open after History was slow to open?
Yes if you are suspecting that the slow load of empty history after loading a 2 GB project started in 2.1.0, you could test that in your Vista machine.
I think you should reboot any computer from time to time, even laptops.
B and C shortcuts not working was a bug in 2.1.1, now fixed.
It sounds like you should experiment with closing History when the project is open and closing the project when History is open (whether History was slow to load or not) and see if you can find any pattern of worsening performance compared to previous Audacity. For example is a project slow to close because History is open? You should test with as few other apps open as possible, because other apps doing something at the same time could skew the results.
I have not tested yet with large projects but will do so if you can see any definite pattern emerging.
Gale
+1
Same goes for routers too (even though they have no bearing on this particular issue).
WC
I’m still gathering timing data for testing my hypotheses. I wanted to use this fixed 2.1.1, so I downloaded what I thought would be the “final” build of 2.1.1 but it still has the bug. Build date was 7/11/2015. Can you point me to the fixed version?
Thanks
If a release (for example, 2.1.1) contains a bug, we never go back and re-release that release. The bug is fixed at some stage in the -alpha nightly builds for the following version (2.1.2-alpha in this example) and the fix will then be available in the next release (2.1.2 in this example).
The fix for this bug was made in July 2015 http://bugzilla.audacityteam.org/show_bug.cgi?id=1085#c6 so should have been fixed in any 2.1.2-alpha after that date, in any of the 2.1.2 release candidates, or in the current 2.1.2 release: http://www.audacityteam.org/download/windows.
I suggest you simply upgrade to 2.1.2 release and use that as the benchmark for the latest version.
Gale