search

magland / sortingview

Web app for viewing results of ephys spike sorting
Apache License 2.0
25 stars 8 forks source link

Adding / removing curation labels is very slow #10

Closed lfrank closed 3 years ago

lfrank commented 3 years ago

It can take anywhere from 1-30 seconds or so to apply or remove a label.

lfrank commented 3 years ago

This was particularly an issue when running the webapp at home.

magland commented 3 years ago

I couldn't reproduce the problem on my end (it always takes 1-2 seconds for me). I added a latency test button to the gui. Could you try that out after upgrading sortingview and restarting the task backend? Screenshot:

image

lfrank commented 3 years ago

Thanks. I get 1.87 seconds, but it takes ~3-4 seconds for the labels to appear / disappear from my home machine and about 2 seconds on the work machine. Note that the message "Finished task: workspace_sorting_curation_action.1” appears almost immediately, but the label takes longer. Is that due to polling?

On Jul 5, 2021, at 3:03 PM, Jeremy Magland @.***> wrote:

I couldn't reproduce the problem on my end (it always takes 1-2 seconds for me). I added a latency test button to the gui. Could you try that out after upgrading sortingview and restarting the task backend? Screenshot:

https://user-images.githubusercontent.com/3679296/124520725-461f2080-ddbb-11eb-9e52-f0c9cff0f72e.png — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/magland/sortingview/issues/10#issuecomment-874346146, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV4PSJXKM6HSAZWURNFGC3TWIT3DANCNFSM47Z6UJUQ.

magland commented 3 years ago

Okay thanks. I have just added a new latency test that includes both a query to the backend and appending a subfeed message. See screenshot below. This second task takes around 1.6-2 seconds for me. In the future we can speed this up, but for now it would be helpful to know whether or not you are getting around the same timing.

This requires upgrading sortingview python package on the backend and restarting.

image

lfrank commented 3 years ago

Here’s what I get for the work computer and about the same at home:

I’m using a VPN to get in to UCSF, so perhaps that is why mine is slower…

On Jul 5, 2021, at 6:28 PM, Jeremy Magland @.***> wrote:

Okay thanks. I have just added a new latency test that includes both a query to the backend and appending a subfeed message. See screenshot below. This second task takes around 1.6-2 seconds for me. In the future we can speed this up, but for now it would be helpful to know whether or not you are getting around the same timing.

This requires upgrading sortingview python package on the backend and restarting.

https://user-images.githubusercontent.com/3679296/124529161-eaaf5b80-ddd7-11eb-9d6e-c875b9208b8b.png — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/magland/sortingview/issues/10#issuecomment-874396669, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV4PSMH2NEMFMRAQZZYBOTTWJL37ANCNFSM47Z6UJUQ.

magland commented 3 years ago

@lfrank, was there supposed to be a screenshot? I don't see any timings.

lfrank commented 3 years ago

Not sure what happened there, as I see the screenshot in my email, but here it is again:

And I’ll try upgrading sortingview shortly...

On Jul 5, 2021, at 6:49 PM, Jeremy Magland @.***> wrote:

@lfrank https://github.com/lfrank, was there supposed to be a screenshot? I don't see any timings.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magland/sortingview/issues/10#issuecomment-874402613, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV4PSMPUNTBCZ6OIAJRL4DTWJOMDANCNFSM47Z6UJUQ.

magland commented 3 years ago

Unfortunately I don't see these screenshots in the emails, and they don't appear on github. I think you may need to paste the image on github website issue tracker for it to go through.

lfrank commented 3 years ago

Trying again...

Screen Shot 2021-07-05 at 6 35 20 PM
magland commented 3 years ago

Okay thanks. Seems to be around 1 sec slower than mine for both tasks. I'm not sure how to explain that -- but let's keep an eye on it. Ultimately we can move to an offline-first model where the curation steps will be instantaneous, but this slower method is safer during development.

magland commented 3 years ago

Closing for now, will revisit.

acomrie commented 3 years ago

Hi all, just adding to this conversation that I have still been experiencing long latencies for adding labels. Just reading this issue thread now, so I have not used the latency timer tool discussed. That said, my experience is that the labeling is much slower when interacting with larger numbers of units at a time. This is especially prevalent when working with larger sorts (such as probes, rather than tetrodes, in the Frank lab). I also have found that the time to add a label can be pretty inconsistent. Occasionally, labels add basically instantly, especially when only a few (say, 1-5) units are selected at a time. However, if I am adding or removing labels from many units - say, 20+, in a sort with ~240 clusters - then oftentimes the labels won't ever display in the units table no matter how long I wait, until after fully refreshing the page in the browser and reopening the units table. Refreshing the page has very reliably solved this, but this solution currently also means reopening views and reselecting units that were previously open before refreshing.

acomrie commented 3 years ago

Sorry - just following up on this - the latency to select units can also be quite slow. Can open as separate issue if useful. Would there also be a way to track/monitor this latency? Have only ever noticed it on large sorts with, say, 240 clusters total. As I try to select/highlight more and more units, it can be (but is not always) very slow for the display to catch up with my unit selections. Thanks for any advice.

lfrank commented 3 years ago

Alison - can you include the url so Jeremy and Jeff can look at this directly?

On Aug 8, 2021, at 4:52 PM, acomrie @.***> wrote:

Sorry - just following up on this - the latency to select units can also be quite slow. Can open as separate issue if useful. Would there also be a way to track/monitor this latency? Have only ever noticed it on large sorts with, say, 240 clusters total. As I try to select/highlight more and more units, it can be (but is not always) very slow for the display to catch up with my unit selections. Thanks for any advice.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magland/sortingview/issues/10#issuecomment-894876041, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV4PSM4MB2N4XZF7DSWBR3T34KDTANCNFSM47Z6UJUQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.

acomrie commented 3 years ago

Absolutely, here's an example I've been interacting with recently. Thank you! [https://sortingview.vercel.app/workspace/sorting/R-c5089c48b72f/S-816a8e175985?workspace=e5c306c436a9f75fd97a20d832cd54d8243d516da53cbfe86270f11e98ee8b26&channel=franklab]

magland commented 3 years ago

@acomrie could you please open two new separate issues for this? One for slow-adding-labels and one for slow-selecting-units? You can reference this issue. Thanks!