I've was running 2014.137 until recently when I upgraded to .210 (and subsequently .213). Everything is much slower with these newer versions.

The reason seems to be excessive disk I/O. I note that simply placing a roughly 2MB image on a page causes hundreds of MB of disk reads! I've seen the same thing on two different Windows installations (Win7 32 and 64-bit) and also in Linux under Wine. Even deleting an image from the page, which shouldn't involve reading any data, causes vast amounts of activity.

I'm reverting to .137 for now!

Sorry, that's not the case. I've watched what happens with both Windows and Linux monitoring tools and it's perfectly clear that the disk I/O is in direct response to my actions. The exact same actions in .137 are fine. It is consistent and repeatable across three very different environments: real PC running Win7/32; VM running Win7/64; PC running Linux+Wine. If the images are on a remote drive, I see huge network transfers, not local disk.

Whatever is happening, it's absolutely real.

Perhaps I'm not making myself clear.

This isn't a minor difference due to reading EXIF data for new functionality, this is a massive difference which can only be due to a program bug. Obviously not one that shows up in all cases, but with the job I'm trying to do, it's absolutely consistent.

This is sluggish to the point of near-unusability even from a local disk, and with a GbE network connection to an SSD or a virtual network connection that's actually local physically, performance isn't much different (good or bad).

I'm talking several seconds for almost any operation, no matter how simple, such as just removing an image from the queue!

So if I:

• Run the .137 installer; start QIU; load my job; start working on it; everything is great.
• Run the .21x installer, overwriting the .137 installation; it's treacle.
• Re-run the .137 installer; back to normal.

Will do, but seriously, this is not swapfile thrashing or anything like that. I'm a software developer myself and I know a program doing something grossly wrong when I see it  :-)

When I see hundreds of megabytes - this is not an exaggeration - being read simply to open a 2MB image with no other stress factors on the machine, that is not correct behaviour!

And here are some Sysinternals Process Monitor logs of the drag-to-page operation. It's interesting that the 213 log is about 54MB and the 214 log just over 60, despite 213 being noticeably slower. OTOH, the 137 log is 4 - four! - MB. That's an awful lot of I/O that wasn't happening before.

Some of the issues are obvious, such as file I/O on every mouse move event when the pointer is over a thumbnail, but that'll mostly be cached by the OS and fast enough not to be a problem on a modern system. Other stuff I don't understand at all, such as the many attempts to access the offline files cache (c:\windows\csc) when I've got offline files disabled.

http://stvren.webspace.virginmedia.com/ProcmonLogs.zip

BTW no argument that 200 is slower when you get into larger print jobs (over about 100), I just don't attribute it to disk I/O.  I just did a job of about 250 prints and did some diagnostics on where the code is spending most of its time by putting in timers.  Turns out that disk I/O contributed very little but the most time was being spent decoding of the JPEG thumbnails.  When I replaced the JPEG thumbnails with uncompressed BMP images (still from the disk), things were nearly instantaneous even though it was using even more disk reads for the larger size BMP files.  Obviously that's not going to be my solution but I'll look later to see what I can do about using another method to check page formatting rather than using the thumbnails to discover size and cropping.

Mike

Ok, I've analysed the procmon logs and I now know more about what's going on, if not why.

This is for a simple drag'n'drop from the folder thumbnail listing to a new blank page at the end of an existing multi-page job. All files are on the local drive and I'm only looking at file read events.

137: the file being placed on the page is read. The process is horribly inefficient, though, as it involves over 2,200 separate read operations, almost all of which are for only a single byte, and many bytes are re-read twenty-five times! Yes, of course, most of those will come from OS cache, but it's still a hell of an overhead calling into the kernel like that rather than maintaining a single in-memory copy.

214: starts much as 137 although the exact pattern of reads is slightly different and actually comes to about 2,400 operations. However, it then goes on to issue 179 reads for every file in the job queue again mostly reading one byte at a time. With 64 images in the queue, this adds up to over 11,500 ops! Remember that I'm appending to the end of the queue on a blank page: nothing whatsoever has changed that needs re-reading.

But it gets worse. I edit the page and change the picture location, just typing a number into one of the position boxes.

137: It just moves the picture.

214: Over 23,000 read ops! Again the whole queue mostly one byte at a time.

Sorry, Mike, but that's a bug in my book. I haven't even looked at other I/O ops than just reading my data files, but there's clearly something wrong.

First, you are making many assumptions about what needs to be done and what you think should be done.  Your heuristics are also wrong.  There is nothing that is reading one byte at a time and certainly not the same byte over and over: your report may show that but it is inaccurate.  There are also times that QU saves undo information after certain operations.

Second, none of that matters in 215 as it is efficient and there are no unreasonable delays.  Even with hundreds of images in the queue, performing an operation only results in a few MB being read from the HD.  There are times when you add an image or move an image that can affect pages other than the one you are working on and I'm certainly not going to rewrite the program to build special cases that optimize things like freehand or single page editing when it'll only save maybe 4 MB of disk reads (reads that have already been cached into RAM) and a quarter second.  So 215 is both efficient and manageable from a code standpoint.

Mike