Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #9329 (closed)

Opened 11 years ago

Closed 11 years ago

Profile the OME-TIFF writer

Reported by: mlinkert Owned by: mlinkert
Priority: minor Milestone: OMERO-4.4.4
Component: Bio-Formats Version: n.a.
Keywords: n.a. Cc: sbesson
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.


We've had reports that writing OME-TIFF files (especially through MATLAB) is slow; Sebastien say that it takes ~45seconds to write 1000 256x256 planes using bfsave.m.

While this isn't terrible, there is probably room for improvement, so it would be nice to run the OME-TIFF writer through a profiler (I've been using JRat) and see what the bottlenecks are.

Change History (5)

comment:1 Changed 11 years ago by sbesson

As the first step of a performance test, wrote a script comparing the execution time of bfsave/Matlab imwrite (https://gist.github.com/3088736)

Ratio of execution times varies between 2-10 depending on image size. This can certainly be improved in the Java code as I don't expect the overhead from copying arrays to account for such a large ratio (cf estimated overhead time ratio ~1.5-2.5 from bfopen.m).

comment:2 Changed 11 years ago by mlinkert

  • Milestone changed from OMERO-4.4.x to OMERO-4.4.1

comment:3 Changed 11 years ago by mlinkert

As far as I can see, the performance issues can be reasonably addressed with this commit:


...which is a change to bfsave.m, and not a change to the underlying TIFF writing logic. Sebastien, can you please confirm that that commit works and is dramatically more performant?

comment:4 Changed 11 years ago by sbesson

Tested with 1000 256x256 images: bfsave function executing ~3X faster than previously.

Also pushed a commit implementing a test case for this ticket:


comment:5 Changed 11 years ago by mlinkert

  • Resolution set to fixed
  • Status changed from new to closed

PR from Sebastien merged into my sprint2-bug-fixes and BioFormats-Matlab updated to reflect the fact that anyone writing planes sequentially should really use the setWriteSequentially method in IFormatWriter.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.70923 sec.)

We're Hiring!