It would be helpful if we could test the same image. Please upload and/or send us a link.
With your file, I get this:
$ time gmic infile.png tic fx_pixelsort 1,0,2,1,0,100,0,0,0 toc output outfile.png
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'infile.png' at position 0 (1 image 3072x4080x1x3).
[gmic]-1./ Initialize timer.
[gmic]-1./ Elapsed time: 1.075 s.
[gmic]-1./ Output image [0] as png file 'outfile.png' (1 image 3072x4080x1x3).
[gmic]-1./ End G'MIC interpreter.
real 0m4,494s
user 0m6,398s
sys 0m0,576s
Note that the most time is spent for saving the outfile.png file. The pixel sorting algorithm takes 1.075s here. I can’t do anything to speed up the saving, as it is something delegated to the libpng library.
I hope I didn’t come across as complaining about execution time with the new patch. I’m very happy with the performance, and understand that I/O will be the biggest botteneck.
No worries, but I was trying to figure out why it didn’t seem to be faster for you.
If it’s coming from the I/O, indeed, there is not much we can do.
Thanks again for reporting this regression from 3.1.3! 