Copy-Segmentation from previous slice is slow

[cnzqy1]

In volume segmentation mode, the performance of copying segmentation (using V or SHIFT + V) deteriorates significantly after repeatedly using it for a few consecutive slices. It could take many seconds for the operation to complete, or the UI could hang completely. The only resolution is to refresh the page which gets this function to work properly, but this issue happens again after a few more slices.

This happens in both version 20.05.0 and 20.06.0, so it is likely not related to #4602 and #4623.

[cnzqy1]

I did some quick troubleshooting with other team members. On my Windows 10 computer, I have this issue in any Chromium-based browser (e.g. Google Chrome, the new Microsoft Edge), but not in Firefox. Disabling all extensions did not resolve this issue in Chromium-based browsers. On other people's macOS computers, they don't have this issue in Google Chrome.

Looks like this could be some OS-dependent compatibility issue with Chromium. Not sure how high the priority this issue is for your team, but I'm happy to troubleshoot further if there is any other information that could help resolve this issue.

[philippotto]

Thank you for the detailed report!

I'm happy to troubleshoot further if there is any other information that could help resolve this issue.

This would be very helpful, since our core team does not use Windows currently. Could you open the Chrome DevTools and record the performance while using the "copy segmentation"-feature? Ideally, the recording should contain the first few usages which are fast and then a slow one, so that we can analyze in which exact parts the performance deteriorates.
If you could export the performance recording (there's a "Save profile" button which creates a JSON file) and attach it here, this would be super helpful.

In case the recording crashes (which is not unlikely, since the performance is already poor without the recording), please try it again and maybe stop it a bit earlier so that we have something to work with, nevertheless.

Thanks for your help! Let me know, if you have any questions!

[cnzqy1]

Performance.zip

The zip file contains two JSON files, 1 is when the copying is relatively fast, and 2 is when the copying is much slower. Performance recording only includes the copying action (I started the recording before hitting the copying keyboard shortcut and stopped the recording after the copying is done). I couldn't get a recording for any copying action when the page completely hangs.

[philippotto]

Thank you very much for the recordings! It's not immediately obvious to my why the performance is so poor on the described system. However, the general implementation of this feature is not optimized at all, anyway. So, we can definitely try to improve on that.

I wrote down some notes regarding how this speed up could be implemented (sorted by effort and impact high-to-low):

• Labelling is done per voxel (independent of bucket). This is expensive since a lot of work could be saved by doing it once for the current bucket. When implementing the operation per bucket, the function getBucketAddressesInCuboid could be helpful.
• Avoid high amount of triggers and setTimeouts. Right now, volumeLabeled and bucketLabeled is triggered after each labeled voxel. This creates a lot of unnecessary overhead.
• The label method already supports using a label function ("labelFunc") which can act on an ArrayBuffer. This should be used to look up the existing voxel value (which is done to check that it's equal to 0). This would save the getDataValue operation which is done before labeling each voxel.

@cnzqy1 We will keep you up to date in this issue once the performance has been improved. I can't make hard promises about an ETA, though.

[cnzqy1]

Thanks a lot for the info! I have a gut feeling that this might be a bug in Chromium on Windows and webKnossos just happens to trigger that. The performance drop off in consecutive copying actions is extremely sharp, meaning that I might have 4 copying actions that run roughly at the same speed, then the 5th one is much slower, and the 6th one completely hangs. I also noticed that the number of copying actions it takes to hang is dependent on the number of voxels labeled and being copied, meaning that I could get 20 copying actions without hanging with fewer labeled voxels but 3 with more labeled voxels.

In any case, I think the performance of this function is definitely acceptable, although if there are low-effort optimizations they certainly would be helpful. Thanks again!

[philippotto]

Thanks for the input!

I also noticed that the number of copying actions it takes to hang is dependent on the number of voxels labeled and being copied, meaning that I could get 20 copying actions without hanging with fewer labeled voxels but 3 with more labeled voxels.

Sounds like it has something to do with memory / garbage collection.

In the mean time, I suggest to use Firefox if this is possible :)

[MichaelBuessemeyer]

Hello @cnzqy1,

I just tried to reproduce this problem on Windows using Chrome but was unsuccessful.
Could you please check, whether this is still an issue?

It might be resolved by now due to the following reasons:

• As you wrote, this problem is dependent on the browser and the operating system (OS). This makes it likely that this is a bug in Chrome for Windows or Windows itself. This bug might be resolved in recent updates. If you update Windows and Chrome, does the problem still exist?
• The second reason why this might be resolved is that more than a month ago we made a big redesign about volume annotation in PR Multi-Resolution Volume Tracings #4755. This PR also changed the implementation of the copy segmentation feature. Therefore this problem might not occur anymore.

[cnzqy1]

I just checked and found this no longer to be an issue with the latest version. Thank you!