I have done exactly that. 8 seconds vs 1 or less. These are manually timed so a bit difficult to be more precise, but precision is hardly needed with that level of difference.

I've told you exactly what I did, I've told you what Qimage is doing from the Windows internal POV, I've offered you a VM copy of my test system (ok, it's a bit big to post here!). Tell me what more you want and if I can I'll do it.

It's a GbE network and the remote disk is an SSD. File transfers can happily max out the link at a solid 100+MB/s.

ISTM it's the round-trip latency that kills performance. Are you telling me that in your tests you don't see a factor of 4.5 increase in I/O ops from 137 to 216?


But the operation I'm focussing on is the one with problems, not the many without! I'm not for a moment saying that there have been no gains in performance generally, merely that there have been significant losses in an area that affects me directly. Those losses have been reduced in the progression from 213 to 216 but not eliminated.

Thanks for that.

True or not, I've had the impression so far that you don't think my concerns are legitimate. Now I fully appreciate that there can be issues that don't affect most people and therefore aren't top of the priority list, but that's a very different thing to suggesting that the issues don't exist.

Let me just reiterate: I'm a software developer myself and I know full well that customers can have problems that are near-impossible to replicate. Lordy, do I know that! And sometimes it's true that they're complete idiots and everything they say is at best irrelevant and at worst a blatant lie!

I'm trying very hard to convince you that I'm not in that category. I've written file system drivers for Windows - indeed, entire file systems for proprietary OSs - and when I say that a large number of redundant operations are happening, it's not because I'm stupid and wrong.

Now sure, there are times when it's quicker to do something unnecessarily than work out whether it's necessary or not: BTDTGTTS! But I'm sorry to have to say this, but I've had the strong impression that I've almost been called a liar rather than being told that unfortunately my use case has had to suffer for the greater good.

It is not ok for me, and if it's ok for you then there is clearly something different about what you and I are doing and/or our test environments. I would like to work out what that is, not just hypnotise myself into believing my problems are imaginary.

"It doesn't do that here" is an experience that every professional software developer knows well. It does not mean there is no problem.

Let me spell out some more details: I have a custom 295x295mm page, print-to-file set, and I'm placing images freehand. The intent is to create pages for uploading to an online print service to make a photobook. Pages generally have around 5-6 images, just less than 6x4 (147.5x98.4 mm) or submultiples. The images are JPEGs with a resolution that works out to 600dpi at the print size. They are held on an SSD on another machine connected via a Gbe network.

If you can duplicate this configuration and still get instant response, I'd be really interested to see your procmon log. There is no doubt that in my tests, Qimage is doing a lot of redundant I/Os. It may be that this is a red herring: they're not the cause of the slowdown. It may be that it doesn't do them if some other condition applies. Whatever it is, I'd like to know!

About using QU.
One "trick" you could use is to deal with 1 or 2 pages at a time and save each as a Job. In that way you will limit the number of images that have to be processed at one time and probably make it easier to organise the book. When the whole book pages are all complete you can then process each page set.
Although I think the above is the better way in your case, if you wanted to process all pages at once, save as a Session so that when recalled, you can append each session one at a time to make the complete book. Make sure the P2F is set before you recall the sessions.
I regularly make "book" or "album" pages for my own records and do use the latter method when printing more than a few pages.
Terry

Sounds good! I look forward to trying out 217 :-)

Thank you for your assistance!

Mike