-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize loading from S3 #677
Comments
Ideas:
|
…s not slow down initial loading too much, looks like a big improvement
Adding Adding however Question to @KateMoreva : Can we get possibly get rid of the "doesObjectExist()" call, which appears to take halve of the time? |
See here: mobie/mobie-io#91 |
Is this to get the data type? If so, I think we probably only need to do this once, data types shouldn't be mixed in the same grid...
Yeah, I think it's better to do EAFP (easier to ask for permission) rather than LBYL (look before you leap) here to improve performance when accessing things on s3. |
I think I do it only once, but already that is very slow. This is a recurring issue and maybe something will change here at some point: imglib/imglib2#312. I'll keep on debugging here as much as I can. I am making very good progress on other fronts, though. Things should get significantly faster now. |
If you just want to get the datatype you can also get it from the metadata, e.g. the .zattrs. That is probably much faster than doing it the imglib way. |
Very good point... But I am not sure how to implement your idea, because I need the |
You'll probably need to write a function that translate the type you get from the metadata (which will be a string?!) to the corresponding imglib2 type. |
Turns out that
was nonsense, because there is:
which apparently is already initialized and thus returns almost instantaneous instead of taking 500 ms 🥳 . |
To better see what is happening, I worked a lot on the logging as well. I also introduced a variable (currently 100ms), and I am only logging what takes longer than this, in order not to clutter the log window, makes sense? Based on the few measurements below (this is from home, for my Mac, which has 4 CPU) I think I will keep 16 IO threads for now as the default. Clearly, multi-threading during IO helps. Any ideas how to do this more systematically? Should we expose the numIOThreads in the UI? 1 IO threads
4 IO threads
16 IO threads
32 IO threads
|
Yeah, I think that makes sense.
16 threads sounds reasonable; in any case, I think it makes sense to have more threads than cores here since these things are usually not compute bound. I am not sure if there's a better way to determine the number of threads, so I think 16 sounds ok for now. |
I checked with the new MoBIE-beta now and it works much better already. I can load the full grid from s3 now in a reasonable amount of time. |
I am closing this as I think we exhausted the options discussed in this issue. |
Bottlenecks:
MergedGridSource
MergedGridSource
:this.type = Util.getTypeFromInterval( referenceSource.getSource( 0, 0 ) );
getMask()
MoBIEHelper
:getMask()
:The text was updated successfully, but these errors were encountered: