Hello Øyvind, thanks for the reply. On 17 April 2011 14:24, Øyvind Kolås <pippin@xxxxxxxx> wrote: > On my c2d 1.86ghz laptop I get 105s real 41s user with default settings. > Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping > of tiles makes it run in 43s real 41s user. I found GEGL_SWAP=RAM, but on my laptop the process wandered off into swap death before finishing. Is there some way to limit mem use? I only have 2gb. > Loading a png into a tiled buffer as used by GeglBuffer is kind of > bound to be slow, at the moment GEGL doesnt have a native TIFF loader, You can work with tiled tiff straight from the file, but for sadly for striped tiff (as 90%+ are, groan) you have to unpack the whole file first :-( >> babl converts to linear float and back with exp() and log(). Using >> lookup tables instead saves 12s. > > If the original PNG was 8bit, babl should have a valid fast path for > using lookup tables converting it to 32bit linear. For most other OK, interesting, I shall look at the callgrind output again. >> The gegl unsharp operator is implemented as gblur/sub/mul/add. These >> are all linear operations, so you can fold the maths into a single >> convolution. Redoing unsharp as a separable convolution saves 1s. > > For smaller radiuses this is fine, for larger ones it is not, ideally > GEGL would be doing what is optimal behind the users back. Actually, it works for large radius as well. By separable convolution I mean doing a 1xn pass then a nx1 pass. You can "bake" the sub/mul/add into the coefficients you calculate in gblur. > It is useful, but it would perhaps be even more useful to see similar > results for a test where the loading/saving is taken out of the > benchmark > and measure raw image data crunching. Yes, good point, it should be easy to instrument it for this kind of test. I'll have a go. John _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
