Well, when I have to select 400-500 keepers from 2500 frames, and I want to get them out to the sports information department and the teams as soon as possible, little things do add up very quickly. 2 extra seconds spent on 400 frames is about 13 minutes, not to mention the frustration of waiting for the next frame to load.
Besides, the tuning work I did on KPhotoAlbum made it better for everyone 
A large number of cmsDoTransform calls is appropriate, the function is arranged so a user can call it “per-stride” and do their own parallelization. However, 28000 does sound large, as the stride normally corresponds to a row of pixels in an image…
If it’s one call per row, that sounds about right (modulo opportunities for caching) then, since I was flipping back and forth between two images, 20 and 24 MP, several times.
I guess I’ll just have to create a profile that turns everything that does color management off, then. But even with color management, this strikes me as very slow on a modern CPU. There must be quite a bit of other processing going on.
UPDATE: I just re-profiled it, and it looks like it’s spending a lot of its time in various GTK drawing operations, which I think can be a lot faster than what I’m seeing. I’m also seeing a lot of time spent in internal pixel conversions that are done by function call that isn’t getting inlined; that’s adding up too.
So, I scrolled back a bit, and found that the problem du jour is ‘crop’ For that operation, should not an initial image be produced, and suffice through various iterations of crop? Or, am I not understanding the dynamic… very probable.
Who’s doing all that huffin‘ n‘ puffin‘? RT or a GTK component?
Who’s doing all that huffin‘ n‘ puffin‘? RT or a GTK component?
With default settings, it’s mostly LittleCMS that’s easing up the time. Going to a completely unmanaged workflow, it looks to be a good part of both. With all the threading it’s a bit hard to interpret the callgrind output, but I’d say it’s probably in the range of 1/3 RT and 2/3 GTK. Watching the UI in action as I flip between images suggests that that’s likely not to be too far off the mark. It’s very possible that inefficiencies in the UI are forcing RT to do more computation than necessary.
kcachegrind doesn’t seem to provide a convenient way to cut and paste from the function list, or I’d cut and paste some of it in.
So, I scrolled back a bit, and found that the problem du jour is ‘crop’ For that operation, should not an initial image be produced, and suffice through various iterations of crop? Or, am I not understanding the dynamic… very probable.
As long as I can extract the geometry of the crop and rotate operations from the sidecar files (and can live with the high ISO image noise), I don’t need RT to actually produce an image, so there’s no need for color management for what I’m doing here (that’s not true for other things, where I actually do want to adjust color).
ImageMagick (via the convert command) appears to be a lot more efficient (not to mention that I can parallelize the images to be processed) than RT. So once I’ve gone through and cropped and rotated the images as needed, I can simply take the sidecar files and apply the geometric transformations to the image files, in addition to adding a watermark, all in one shot. It takes me no more than a few minutes to process 300-400 photos on my E3-1505v5 (i7-6820HQ/i7-6920HQ) laptop; if I ran it on my Ryzen 3900X server, I wouldn’t really have time to get a glass of water.
Have you tried the various GDK_RENDERING environment variable settings? I came across that recently and wondered if it would have any effect on windows or mac.
With GDK_RENDERING=recording, the UI flickers badly. Otherwise, no difference in performance.