Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 01-24-2014, 10:30 AM   #1
mim
Human being with feelings
 
Join Date: Mar 2009
Posts: 370
Default REAPER performance thread - Undo performance (FIXED)

For some time, I feel there are some performance issues with the undo system. The more data (mainly envelopes) is in the project, the more REAPER is getting slow; until I disable undo, then REAPER is blazing fast.

To show my point I made this experience :

Join to this post is a one track project for REAPER.
I've translated this project to another DAW (also joint to this post).

I duplicated this track to have a 128 tracks REAPER project.
I duplicated this track to have a 128 tracks project in the other DAW.

Then, I select (only) one track in REAPER and duplicate it. REAPER creates an undo point and duplicate the track. It takes approx 8 secondes here.

In the other DAW, I select (only) one track in and duplicate it. It creates an undo point and duplicate the track. It takes approx 0.2 secondes.

Those are the LiceCaps:

REAPER (UNDO enabled):THE OTHER DAW (UNDO enabled):

This is a licecap where I disabled UNDO :

REAPER (UNDO disabled) :


Conclusion


There seems to have a way to handle UNDOs in the other DAW that is much more efficient. Once I disable the UNDO in REAPER I get the same level of performance.




Attached Files
File Type: zip OneTrackWithVolAutomation.zip (223.0 KB, 175 views)
File Type: zip 1Tracks-VolEnv-3600sec.zip (205.5 KB, 162 views)

Last edited by mim; 01-24-2014 at 10:41 AM.
mim is offline   Reply With Quote
Old 02-25-2014, 07:12 PM   #2
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Yes, undo performance in cases of a very very large amount of automation could be better.
Justin is offline   Reply With Quote
Old 03-02-2014, 06:57 PM   #3
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

There is an update in 4.61pre1 which may help this (though not completely eliminate the problem, some bigger structural changes will likely improve this further later on).
Justin is offline   Reply With Quote
Old 03-02-2014, 10:21 PM   #4
miche
Human being with feelings
 
miche's Avatar
 
Join Date: Jan 2009
Posts: 559
Default

Quote:
Originally Posted by Justin View Post
Yes, undo performance in cases of a very very large amount of automation could be better.
Just wondering, and not wanting to hijack the thread (sounds like a similar issue to me): could there also be optimization in case of very very large amount of items & groups? I see major slowdowns in such projects when using reascript. Or is it a normal, expected thing?
miche is offline   Reply With Quote
Old 03-03-2014, 12:28 AM   #5
mim
Human being with feelings
 
Join Date: Mar 2009
Posts: 370
Default

Quote:
Originally Posted by Justin View Post
There is an update in 4.61pre1 which may help this (though not completely eliminate the problem, some bigger structural changes will likely improve this further later on).
Great ! I'll test and report.
mim is offline   Reply With Quote
Old 03-03-2014, 04:01 PM   #6
Shootkin
Human being with feelings
 
Join Date: Oct 2013
Location: Russia
Posts: 298
Default

Quote:
Originally Posted by Justin View Post
There is an update in 4.61pre1 which may help this (though not completely eliminate the problem, some bigger structural changes will likely improve this further later on).
Definitely much faster, thank you! I tested mim's files in 4.60 and 4.61. Undo is still a little bit slower than Cubase but personally I'd live with it as it is now.

Last edited by Shootkin; 03-03-2014 at 07:03 PM.
Shootkin is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:22 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.