Is anyone still observing that "Mutate Sidechains feature takes too long to stop"?
If yes, can you point me to a puzzle - better yet, the name of a solution file - that reproduces the problem particularly well? (It would be great if you could also provide your computer hardware and operating system info.)
I'd like to look into the issue further and see if I can improve the situation.
Thanks!
"…can you point me to a puzzle - better yet, the name of a solution file - that reproduces the problem particularly well?…"
Every. Last. One.
Shake and mutate are affected on ANY puzzle.
More sidechains selected - it takes looooonger.
"Stopping" message can last up minute or more….
Better in devprev on symmetric hub.
Do you mean that the problem is better on this puzzle, or this puzzle is an even better example of how bad it can get?
If (by some miracle) the problem isn't as bad on this puzzle using devprev, how about on any other design puzzles (in devprev vs. main). For example 636 or 638?
It would be great if the latest devprev update fixed this issue!
For me,in dev prev, the time to stop mutate is higher with local selection than with no local selection.
This time is higher than to stop wiggle, is shorter than before and not annoying.
I've been seeing +30 second stopping times on mutate in 644 using current devprev; sometimes its fast, sometimes glaciers can sweep across the plains of Europe and retreat before it stops.
bump. the problem is really annoying on 656. could this be linked to a sort of memleak? now foldit is using like a third of my ram (4Go), which will drop hard if i start anew. i know the waiting will drop significantly too if i reboot foldit and then will increase by small steps until it becomes unusable and my ram reaches its fullest. i've never seen such problems with shake.
I too experience this slowness in puzzle 656 on an i7-920 2.66 GHz running 4 clients (using 4 Gb and 8 Gb free) with Win 7 64-bit latest 2012-11-19-52243M-win_x86-devprev.
663 Mb after running for a while, stopped and restarted with exactly the same position, now uses 531.
I also recall I reported several revisions of devprev ago there STILL was a memory leak after the mega-leak some time ago. To my knowledge that was never fixed.
So here you have a CONFIRMED memory leak. Upping priority.
After just ONE action of 'mutate all', the M key, it leaves me with 585 Meg, a staggering 54 Megabyte increase… After another wiggle or two and a new mutate we're at 604…