Copy and Paste extremely slow in big projects

rl · 8 Nov 2009

In addition: on schematics with lot's of synchronized elements CTRL-C / CTRL-V does no more work on the synchronized elements. Workaround: use copy/paste from the context menu (right click)

malc · 9 Nov 2009

Hi sunsynth,

Do you have a pre-made schematic you can send me that demonstrates this? If not I can try and make one but if you have one already that will save me some work 🙂

@rl: not quite sure what you meant in your comment. Are you saying that using the shortcut keys behave differently from the context menu?

Thanks,

Malc

sunsynth · 9 Nov 2009

Hi malc,

i don't wanna send my hole mixer-project... sorry

Try any big one and u will notice a delay after copy until SM reacts again!

and It doesn't matter what u copy (even if ASIO is disabled)!

P.S: I have mucho stream, green and bool in my biiig project as u already know 😉 I think it started after 450000 mods but i'm not shure...

Walter

rl · 9 Nov 2009

This is part of my circles synthesizer.

there are 18 synchronized circles (modified knobs). CTRL-C/CTRL-SHIFT-V and CTRL-C/CTRL-V does not work, but Copy/Paste and Copy/Paste Synchronized from the context menu works (with a slow down as with sunsyn's observation (I have to wait about two seconds after copy before I can paste)

malc · 10 Nov 2009

Does CTRL-C/CTRL-V not copy and paste anything at all?

Perhaps the shortcuts are just not being recognised. Do they work in a simple schematic with just a few components?

Both the shortcut and context menu commands call the same code.

Regarding the slow down I have almost located the cause. Could be some over protection that seems to be applied in the copy case but not the cut. I need to check it over to see if it can be removed or at the very least refined.

sunsynth · 10 Nov 2009

Good to hear malc 🙂

I also noticed rl's 2 seconds pause but I am used to this.

Walter

malc · 19 Nov 2009

I got the slow down sorted now I think.

The fix is in the latest beta exe which you can get here: [old link]

sunsynth · 19 Nov 2009

malc - u just made my day! 🙂 😀

...but now i have to count how much weeks working time i've lost waiting 5-10 seconds 4 every copy and paste before 4 my bill!

malc · 19 Nov 2009

Ouch! 😊

infuzion · 20 Nov 2009

sunsynth wrote: ...but now i have to count how much weeks working time i've lost waiting 5-10 seconds 4 every copy and paste before 4 my bill!

Yes, I was pulling my hair out waiting for the copy/pastes before also. One of the main reasons I went on the reduce file size campaign. Glad to hear that it is truly better!

malc · 20 Nov 2009

You can try it out. If you go to the testing area there's a beta exe: [old link]

Let me know if it improves things.

stw · 23 Feb 2011

Sorry to dig this out but... i get that behaviour again. A simple cut/copy and paste of one prim takes up to 90 seconds on my Core2 laptop! I'm not sure when i noticed the reincarnation of the delays first but i guess it was in 1.1.7. Slowely but steady with the growing project which is app. 3.5MB packed and 400000 prims. I'm on 2.0.2 now but with no improvement. Right now it's almost impossible to use cut/paste on a slower machine. Even on my pretty fast i5 imac, it's a pain.

sunsynth · 23 Feb 2011

Yeah - it's really a pain in the a**

Malc changed it back in v1.17 because of probs with the faster beta version... 🙁

trogluddite · 23 Feb 2011

Ever tried replacing the grub screw that secures one of the cogs to a driveshaft inside the gearbox of a large truck?...

...sure, the little screw itself is easy enough to 'cut and paste' - but you've got to get inside that gerabox - and then put it all back together again afterwards. If you have 400000 modules, there are bound to be plenty of places that a 'simple' paste has a hell of a lot of significance to the processing and routing of a multitude of other parts - especially if it involves the flow of green triggers. That's probably why Malc's attempts to speed it up just created bugs - with so many parts, the re-compilation of the schematic has to be very precise.

stw · 23 Feb 2011

trogluddite wrote: ...sure, the little screw itself is easy enough to 'cut and paste' - but you've got to get inside that gerabox - and then put it all back together again afterwards. If you have 400000 modules, there are bound to be plenty of places that a 'simple' paste has a hell of a lot of significance to the processing and routing of a multitude of other parts - especially if it involves the flow of green triggers. That's probably why Malc's attempts to speed it up just created bugs - with so many parts, the re-compilation of the schematic has to be very precise.

Nice metaphor Trog but it didn't hit the point because the recompile isn't causing the trouble here. - Deleting a simple prim takes 2 sceonds. Cutting the same takes 60. Both generate a recompile. - Throwing in a simple prim works without any delay. Pasting the same from a previous cut takes 30 seconds. And it's not big difference between cut/copy a bigger module including many primitives or only one single primitive. BTW The modules are not synced.

aliasant · 23 Feb 2011

stw wrote: trogluddite wrote: ...sure, the little screw itself is easy enough to 'cut and paste' - but you've got to get inside that gerabox - and then put it all back together again afterwards. If you have 400000 modules, there are bound to be plenty of places that a 'simple' paste has a hell of a lot of significance to the processing and routing of a multitude of other parts - especially if it involves the flow of green triggers. That's probably why Malc's attempts to speed it up just created bugs - with so many parts, the re-compilation of the schematic has to be very precise.

Nice metaphor Trog but it didn't hit the point because the recompile isn't causing the trouble here. - Deleting a simple prim takes 2 sceonds. Cutting the same takes 60. Both generate a recompile. - Throwing in a simple prim works without any delay. Pasting the same from a previous cut takes 30 seconds. And it's not big difference between cut/copy a bigger module including many primitives or only one single primitive. BTW The modules are not synced.

I have this problem to in my bigger schems. The bigger the worse the problem. Something is clearly wrong and has been for a while.

trogluddite · 23 Feb 2011

Ah I see, so it is just the use of the clipboard that makes the problem. Agreed - that it very odd behaviour.

infuzion · 24 Feb 2011

Seems if the more bug reports with good explanations emailed to support@ the faster the bug can be fixed.

MichaelBenjamin · 24 Feb 2011

i get this too and somehow got used to waiting 1 minute to copy paste something. dragging things from the toolbox is pretty much instant however. only thing i have observed so far is that the complexity/slowness curve effect becomes noticable quite sudden from some point on and synchronizing adds to it.

stw · 24 Feb 2011

infuzion wrote: Seems if the more bug reports with good explanations emailed to support@ the faster the bug can be fixed.

[x] done

sunsynth · 24 Feb 2011

2 check this unsynchronize behaviour i need the Hot keys combination to do it in one go... totally forgot that 😊

Who knows it?

stw · 25 Feb 2011

sunsynth wrote: 2 check this unsynchronize behaviour i need the Hot keys combination to do it in one go... totally forgot that 😊

Who knows it?

Hold CTRL+ALT+SHIFT and press S ... and the issue is definitely addicted to the amount of synced modules. I had a short conversation with malc and he is focused on the problem. So far every cut/copy seems to search the whole schematic more than once to avoid any trouble with synced modules which makes it incredible slow if your project contains hundreds of them.

DigitalWhiteByte · 25 Feb 2011

I confirm what you say, in fact you may notice a slowdown, even when you connect or disconnect a wireless in a module that is synchronized with many other modules.

sunsynth · 25 Feb 2011

Good 2 know stw... glad u could motivate malc 2 dig deeper or simply remember him about this prob...

Hold CTRL+ALT+SHIFT and press S

Thanks - i knew it was so 'simple' 😉