help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Profile, imwrite and __magick_write__


From: Michael Goffioul
Subject: Re: Profile, imwrite and __magick_write__
Date: Wed, 22 Jan 2014 14:06:03 -0500

On Wed, Jan 22, 2014 at 1:59 PM, ijourneaux <address@hidden> wrote:
I am using Octave 3.7.2+ VS2010 and was trying out the profiling
functionality to see if I could improve the performance of the Octave
routine I am using.

It turns out that most of the time is consumed in imwrite and the routine it
calls __magick_write__.

Is there anything I can do to improve the performance? I am reading image
files, processing them and saving them out again. I was surprised that the
__magick_read__ was substantially less than the __magick_write__.

Take Care

octave-qt.exe:5> profshow(T)
   #         Function Attr     Time (s)        Calls
----------------------------------------------------
 122 __magick_write__           360.592           17
  93            conv2            24.302          109
   6        binary ==            10.697         2524
 123          bwlabel            10.697            7
  16             find             9.344         1005
  90            uint8             5.259           92
  86  __magick_read__             3.941           11
 145         applylut             2.101           22
  29         binary +             0.930         2677
  38              max             0.907         1239
 132        binary .*             0.610           10
  28         binary *             0.564         4704
  23         binary -             0.462         4701
   2        binary !=             0.421         1430
 124           double             0.329           90
  37              abs             0.326           84
   5         binary >             0.301         3490
  19               cd             0.280           15

I'm not an expert in any way, but could it be due to the image format and the fact that compression is more expensive than decompression (I understand that common codecs are more designed to be fast-to-decompress and fast-to-compress)?

When naively googling, I find this reference [1], which doesn't look good for PNG compression :)

Michael.

[1] http://jacksondunstan.com/articles/2117


reply via email to

[Prev in Thread] Current Thread [Next in Thread]