<div dir="ltr">Hi all,<div><div class="gmail_extra"><br></div><div class="gmail_extra">as a fairly general summary of this thread:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> * There will always be hidden costs for Bio-Formats and OMERO to work from a mounted disk[1] and as datasets grow in size, we'll probably have to come up with more comprehensive solutions to issues like these, but that won't be possible for 5.1.0</div><div class="gmail_extra"><br></div><div class="gmail_extra"> * Nevertheless, there is obviously still huge room for improvement. A large part of the underlying problem is that we don't and probably can't regularly test with realistically sized datasets of each file format over various mounting options. This is certainly where you can help! If anyone has similar issues perhaps with other file formats, let us know the details.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> * In the meantime, we'll start working on the formats and components where we know there are issues and keep you posted. If anyone is interested in getting their hands dirty, likely the most helpful information would be Java hprof[2] output or similar from an example run of what you consider slow.</div><div class="gmail_extra"><br></div><div class="gmail_extra">A lovely weekend to one and all,</div><div class="gmail_extra">~Josh</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing">http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing</a></div><div class="gmail_extra">[2] <a href="https://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html">https://docs.oracle.com/javase/7/docs/technotes/samples/hprof.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 10:11 AM, Melissa Linkert <span dir="ltr"><<a href="mailto:melissa@glencoesoftware.com" target="_blank">melissa@glencoesoftware.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Paul and Niko,<br>
<span class=""><br>
> >> Would this bug also explain slowness in the OMERO importer while<br>
> >> importing files which are located on a network drive (in Windows)?<br>
<br>
</span>It's very possible - the easiest way to know for sure is to compare the<br>
import time for the same file on a network drive vs. on a local drive.<br>
<span class=""><br>
> > I doubt this is related - as I understand it, the (current) import process<br>
> > using OMERO.insight just copies the image file(s) onto the server before it<br>
> > is processing them. So the first time the BioFormats kicks in there is<br>
> > *after* the actual transfer and therefore the network drive issue should<br>
> > not apply here.<br>
<br>
</span>That's mostly correct, but Bio-Formats is still used client-side at<br>
import time send metadata to the server and to determine which files<br>
need to be uploaded.  Bio-Formats definitely would be accessing the<br>
files as they are on the network drive.<br>
<span class=""><br>
> You're probably right that the File.isHidden() in BioFormats isn't called<br>
> in the OMERO importer at the client side. However, from quickly grepping<br>
> through the source of openmicroscopy/components/insight I found several<br>
> calls to File.isHidden(). I was wondering if these are also meant to be<br>
> optimized as part of this issue.<br>
<br>
</span>We weren't initially considering the OMERO code base, but once this<br>
issue is resolved in Bio-Formats it likely makes sense to use the same<br>
fix in OMERO.<br>
<br>
Regards,<br>
-Melissa<br>
<br>
P.S. Niko, you are now CC'd on the ticket as well.<br>
<div class=""><div class="h5"><br>
On Thu, Dec 11, 2014 at 09:07:41PM +0100, Paul van Schayck wrote:<br>
> Hi Niko,<br>
><br>
> You're probably right that the File.isHidden() in BioFormats isn't called<br>
> in the OMERO importer at the client side. However, from quickly grepping<br>
> through the source of openmicroscopy/components/insight I found several<br>
> calls to File.isHidden(). I was wondering if these are also meant to be<br>
> optimized as part of this issue.<br>
><br>
> What we experience in the OMERO importer is for very low latency network<br>
> drives that the import is relatively slow (compared to file copy). For<br>
> higher latency network drives the import is slow and the importer UI<br>
> becomes unresponsive (although the import continues). If you want me to<br>
> quantify these experiences, I could do that.<br>
><br>
> Thanks,<br>
><br>
> Paul<br>
><br>
><br>
> On Thu, Dec 11, 2014 at 8:22 PM, Niko Ehrenfeuchter <<br>
> <a href="mailto:nikolaus.ehrenfeuchter@unibas.ch">nikolaus.ehrenfeuchter@unibas.ch</a>> wrote:<br>
><br>
> > Hi Paul,<br>
> ><br>
> > I doubt this is related - as I understand it, the (current) import process<br>
> > using OMERO.insight just copies the image file(s) onto the server before it<br>
> > is processing them. So the first time the BioFormats kicks in there is<br>
> > *after* the actual transfer and therefore the network drive issue should<br>
> > not apply here.<br>
> ><br>
> > I might be wrong, though...<br>
> ><br>
> > Cheers<br>
> > Niko<br>
> ><br>
> > On 11.12.2014 17:29, Paul van Schayck wrote:<br>
> ><br>
> >> Hi Melissa,<br>
> >><br>
> >> Would this bug also explain slowness in the OMERO importer while<br>
> >> importing files which are located on a network drive (in Windows)?<br>
> >><br>
> >> Thanks,<br>
> >><br>
> >> Paul<br>
> >></div></div></blockquote></div></div></div></div>