A bit slow copying on Mac?

[greenmorpher]

PhotoLine 16.51, OS X.6.7, MacBook Pro 2.66 Ghz, 13", mid-2010 model.

I copied a portion of a picture selected with the lasso today -- about an A4 size 300 dpi -- and it took 7 seconds to complete (having been a little taken aback at the first delay, I tried a similar copy several times).

That seems a bit long. Anyone else seeing long copy times?

Cheers, geoff

Geoffrey Heard
Business & Environment Writer, Editor, Publisher
The Worsley Press
Buy "Type & Layout: Are you communicating or just making pretty shapes?" -- the world's ONLY scientifically based guide to type and layout, and receive a free 140 page guide to advertising for small business: "How to make great ads for (small) business: 99 real world advertising ideas to kickstart *your* business today". Amazon or http://www.worsleypress.com

[bkh]

I copied a portion of a picture selected with the lasso today -- about an A4 size 300 dpi -- and it took 7 seconds to complete (having been a little taken aback at the first delay, I tried a similar copy several times).

So that's roughly 2500 x 3500 pixels? I just tried a 10 Mpx jpeg from my camera, selected (almost) the entire image with the lasso and copied and pasted the selection. This is almost instant on my 2009 iMac. Could be a RAM issue, though. If you have too many applications and/or windows open at the same time, the computer has to save some of its RAM contents to hard disk before there is enough space to copy. These days hard disks are so quiet that you hardly notice. Have you tried quitting applications and closing PL windows? You can also use Activity Monitor (and its System Memory tab) to check this - if the "Pages out" count increases while you copy, this should be it.

Cheers

Burkhard.

[greenmorpher]

Cunning stuff, Burkhardt.

I always forget about the Activity Monitor -- ut then I don;t really understand what it is tellinbg me. Good grief -- looking at it and paying attention to the time makes things look even worse! I ran several trials:

Looking at Activity Monitor, "System Memory":

64 BIT MODE:

Resting (i.e. program running but no picture), PL is recording 1.2% CPU and 124.6 MB "Real Mem" running 64 bit.

In the background but a picture now open (4000 x 2672 pixel TIFF), 1.2% CPU, 133.3 MB memory.

With a picture open but PL in front and just running a tool round but not doing anything, ~10% of CPU, 133.4 MB memory.

When selecting whole picture with lasso, ~7-15% CPU, 133.5 MB Memory.

Copying picture: runs up to 100+% CPU, 310.5 MB memory.

Duration: 17 seconds to "not responding", complete in 21 seconds

32 BIT MODE:

Similar, but:

Duraton: 5 seconds to beach ball start, 30 seconds to complete copy (most of that time, PL is "not responding").

Copying picture: runs up to 100+% CPU, 250-278 MB memory.

Duration: 18 seconds to "not responding". complete in 31 seconds.

32 BIT MODE + ROSETTA:

Resting (i.e. program running but no picture), PL is recording 3.4% CPU and 60.7 MB of "Real Mem" running PowerPC.

In the background but a picture now open (4000 x 2672 pixel TIFF), ~3% CPU, 161.4 MB memory.

With a picture open but PL in front and just running a tool round but not doing anything, ~10% CPU, 161.4 MB memory.

When selecting whole picture with lasso, peaked at about 30% CPU, 165.3 MB Memory.

Copying picture: runs up to 101% CPU, 305 MB memory.

Duration: 18 seconds to "not responding", 44 seconds to completion.

Good grief -- I just did another test with the proper stopwatch (instead of just counting), and it ran out to over a minute all told with a second period of "not responding" kicking in shortly after the first period had ended at around 55 seconds.

---

When pasting the picture as a document in 32 bit mode + rosetta, CPU went to 126%. Of what?

---

APERTURE:

I thought I would check out running Aperture also; I was concerned that perhaps there was something wrong with the RAM or whatever because PL seems to use such a low figure (if that's what the memory figures mean). I also tried opening and copying a picture in Aperture. Kind of doesn't do anything! I don't know what's happening -- Aperture is a bit bizarre and elements of it remain a mystery to me. So I tried using the copy brush and found that memory usage shot up and it all registered as it should in Activity Monitor.

Resting: 0.2-4% CPU, 1.24 GB memory.

Using the copy brush: 160% CPU, 2.67 GB memory.

Then I checked PL on this task, using a similar sized brush and similar (sky) tone for copying and dragging the copy brush around in a similar way:

PL using copy brush: 60% CPU, 260 MB memory.

---

Other programs open during the coping exercise with PL were: Personal Organizer (PPC), Firefox 3.6.17, EarthDesk, Typinator -- and Activity Monitor, of course.

Throughout the trial, the minimum of RAM free, according to he Activity monitor is 5.54 GB; it was more than 6 GB most of the time.

Mid-2010 MacBook Pro, 13", 2.66 Ghz Core 2 Duo, 8 GB RAM, 500 GB Seagate Momentus XT HDD (inc. 4 GB SSD -- v.25 firmware).


So something bizarre is happening!

Cheers, geoff

Geoffrey Heard
Business & Environment Writer, Editor, Publisher
The Worsley Press

[greenmorpher]

In 32 bit mode:

Same picture reduced to 1417 x 936 JPEG, copies in two seconds or so. Resting in background, 1.2% CPU, 96-100.6 MB memory, runs up around 67% CPU, no change in memory in copying.

Same picture. 4000 x 2672 but saved as JPEG at 100%+high quality, so a 10.5 MB file. Ha! 27 seconds, including some "not responding" time. Ran up to 99.6% CPU, 224 MB memory.

Sigh!

Cheers, geoff

[bkh]

Other programs open during the coping exercise with PL were: Personal Organizer (PPC), Firefox 3.6.17, EarthDesk, Typinator -- and Activity Monitor, of course.

This Typinator thing made me a little suspicious, so I downloaded the trial (4.4). And indeed, as soon as I use Typinator, I can see the behaviour which you are describing, and as soon as I quit Typinator, all is well again. Pausing Typinator, or assigning no actions to the application PL seems not to be enough.

My guess is that Typinator is "looking" at the clipboard contents, causing PL to use a lot of cpu time as it must convert the data to all the formats which Typinator requests. I don't understand why Typinator does this at all, why does it interfere with image data, or does anything at all while paused …

I always forget about the Activity Monitor -- ut then I don;t really understand what it is tellinbg me. Good grief -- looking at it and paying attention to the time makes things look even worse! I ran several trials:

I didn't really mean for you to look at all the details - the really important numbers are those in the lower part.

Looking at Activity Monitor, "System Memory":

64 BIT MODE:

Resting (i.e. program running but no picture), PL is recording 1.2% CPU and 124.6 MB "Real Mem" running 64 bit.

In the background but a picture now open (4000 x 2672 pixel TIFF), 1.2% CPU, 133.3 MB memory.

With a picture open but PL in front and just running a tool round but not doing anything, ~10% of CPU, 133.4 MB memory.

When selecting whole picture with lasso, ~7-15% CPU, 133.5 MB Memory.

So far, everything seems normal …

Copying picture: runs up to 100+% CPU, 310.5 MB memory.

Duration: 17 seconds to "not responding", complete in 21 seconds

Memory usage is normal, but 100% CPU for 21 secs??? Can't be saving RAM content to disk then, because if that happens, the CPU usage numbers are very low.

When pasting the picture as a document in 32 bit mode + rosetta, CPU went to 126%. Of what?

That's normal - you probably have two CPUs, so that makes 200 % CPU power altogether.

I thought I would check out running Aperture also; I was concerned that perhaps there was something wrong with the RAM or whatever because PL seems to use such a low figure (if that's what the memory figures mean).

I don't think that PL's memory figures are unusually low, for a 10 MPixel image in 8 bit mode, you need 10 MB per color, so that's 30 to 40 MB total. In practice, you'll need a bit more (undo, caches, …) but that's the order of magnitude. Aperture seems to be using system resources very generously, to say the least …

Using the copy brush: 160% CPU, 2.67 GB memory.

Then I checked PL on this task, using a similar sized brush and similar (sky) tone for copying and dragging the copy brush around in a similar way:

PL using copy brush: 60% CPU, 260 MB memory.

Again, this shows that PL is very clever about not using too many system resources.

Throughout the trial, the minimum of RAM free, according to he Activity monitor is 5.54 GB; it was more than 6 GB most of the time.

So RAM definitely isn't an issue here. (But "free" is not that important, "inactive" is just as good …)

Cheers

Burkhard.

[greenmorpher]

Burkhard -- that's sensational! I just quit Typinator and as you reported, PL copies and pastes simultaneously! I didn't even think to look at it -- it is just there all the time, a start-up lauch. I'll report a major bug report to Typinator forthwith!

Hmmm -- makes for difficulties, though, I need to have Typinator running to correct my multitudinous typographical errors. In the good old days, I could type 100 words a minute; today I type 100 typos a minute so I rely on Typinator to correct many of those. I'll just have to remember to pause it when I'm using PL. That's not going to do anything nice to the captions I give my pix after editing them in PL though!

Burkhard, my thanks again, and particular thanks for going to the trouble of downloading and testing Typinator. I used TypeIt4Me for many years, but switched to Typinator only some months ago because of recurring problems with Ti4M in interfacing with my WP of choice, NisusWriter Pro.

You wonder why Typinator is doing stuff while paused. In fact, you're only pausing Typinator's replacement action, not its detection action (which, of course, ought to be paused too -- why detect if you're not doing anything with the information?). Anyway, I'll send the man a rocket!

Phew -- that's a load off my mind!

Best regards

Geoffrey Heard
Business & Environment Writer, Editor, Publisher
The Worsley Press

[greenmorpher]

Actually, there's a codicil to that -- I just tried lassoing and copying the same picture in Canvas with Typinator running -- no problem.

So perhaps there's something about an interaction between the way PL is approaching/using the clipboard and the way Canvas does it. Martin? Gerhard?

Cheers, geoff

Geoffrey Heard
Business & Environment Writer, Editor, Publisher
The Worsley Press

[Martin Huber]

Actually, there's a codicil to that -- I just tried lassoing and copying the same picture in Canvas with Typinator running -- no problem.

So perhaps there's something about an interaction between the way PL is approaching/using the clipboard and the way Canvas does it. Martin? Gerhard?

PhotoLine isn't doing anything special with the clipboard. With images PhotoLine is putting 4 types of data on the clipboard:
- 2 small blocks for copying inside of PhotoLine
- a TIFF for data exchange with other applications
- a PLD for data exchange with a second instance of PhotoLine

Each type is only created, if there is an application explicitly asking for it. The slowest of these types is potentially the PLD, but Typinator shouldn't ask for it, because it can't handle it anyway.

You might speed up copying by modifying the compression setting in Preferences/File/PLD. If you change the compression to "No Compression", you will get the best performance but your PLD files will become significantly larger.

Martin

[greenmorpher]

PhotoLine isn't doing anything special with the clipboard. With images PhotoLine is putting 4 types of data on the clipboard:
- 2 small blocks for copying inside of PhotoLine
- a TIFF for data exchange with other applications
- a PLD for data exchange with a second instance of PhotoLine

Each type is only created, if there is an application explicitly asking for it. The slowest of these types is potentially the PLD, but Typinator shouldn't ask for it, because it can't handle it anyway.

You might speed up copying by modifying the compression setting in Preferences/File/PLD. If you change the compression to "No Compression", you will get the best performance but your PLD files will become significantly larger.

gue, the Typinator man, has been in touch. He says Typinator is fetching the clipboard as it is filled in anticipation of needing to save and restore it. He believes he can fix this, and he'll work on it and test it in the next few days. We'll see what happens!

PL's speed is not a problem for me, Martin, since it is lightning when Typinator is not running. if I anticipte working on something to doing any significant copying, I'll just quite Typinator and correct any typos I type later.

Cheers, geoff

[Neonsquare]

Using the copy brush: 160% CPU, 2.67 GB memory.

Then I checked PL on this task, using a similar sized brush and similar (sky) tone for copying and dragging the copy brush around in a similar way:

PL using copy brush: 60% CPU, 260 MB memory.

Again, this shows that PL is very clever about not using too many system resources.

Actually...not. Its comparing apples and oranges. Aperture's copy brush is fully non-destructive and integrated into its fully non-destructive RAW-workflow. It is capable to compute the preview of all adjustments coming from RAW to the screen preview in realtime. It does heavily rely on multicore processing and GPU computing and intelligent caching of all intermediate structures. Compared to that, the PL copy brush is a quite simple and straightforward action. Thats not to make PL's variant bad - it fits perfectly in this style of application and is indeed usable even on less capable hardware.

ciao,
Jochen

[bkh]

Actually...not. Its comparing apples and oranges. Aperture's copy brush is fully non-destructive and integrated into its fully non-destructive RAW-workflow. It is capable to compute the preview of all adjustments coming from RAW to the screen preview in realtime. It does heavily rely on multicore processing and GPU computing and intelligent caching of all intermediate structures. Compared to that, the PL copy brush is a quite simple and straightforward action. Thats not to make PL's variant bad - it fits perfectly in this style of application and is indeed usable even on less capable hardware.

If you paint on a transparent layer with "merged copy" and "preview on", then PL's copy brush is fully non-destructive and realtime as well, so I don't quite see the difference (with an additional transparent layer, the cpu usage goes up from 60 % to 70 %). OK, PL doesn't allow a raw file as a background layer, but then raw decoding (demosaicing) isn't too CPU intensive, and will only happen once per image if you do any caching. The real question for me is if the result is any different if you use Aperture's copy brush.

Cheers

Burkhard.

[greenmorpher]

Actually...not. Its comparing apples and oranges. Aperture's copy brush is fully non-destructive and integrated into its fully non-destructive RAW-workflow. It is capable to compute the preview of all adjustments coming from RAW to the screen preview in realtime. It does heavily rely on multicore processing and GPU computing and intelligent caching of all intermediate structures. Compared to that, the PL copy brush is a quite simple and straightforward action. Thats not to make PL's variant bad - it fits perfectly in this style of application and is indeed usable even on less capable hardware.

If you paint on a transparent layer with "merged copy" and "preview on", then PL's copy brush is fully non-destructive and realtime as well, so I don't quite see the difference (with an additional transparent layer, the cpu usage goes up from 60 % to 70 %). OK, PL doesn't allow a raw file as a background layer, but then raw decoding (demosaicing) isn't too CPU intensive, and will only happen once per image if you do any caching. The real question for me is if the result is any different if you use Aperture's copy brush.

Oddly, I had the impression that Aperture worked exactly opposite to that -- I rather thought it was operating in a kind of lightweight preview mode and ultimately stored the original plus the completed changes (i.e. ignoring anything that was reversed) for economy of space, then generated the new fully edited image when it was called for. As a result, I was puzzled by its slowness. Now you've explained, Neon, I can see why it is slow -- and I can hardly believe that they have used such a clumsy way of working demanding so much computer power for no advantage in the end. It's plain stupid, if you ask me. As far as I am concerned, as I said on the DPReview Mac forum (to the consternation of many), I think Aperture is a badly thought out and badly made tool -- like a chisel with a bent blade, crooked handle and chips out of its cutting edge -- and I won't be using it any further even though I (foolishly) paid for it. I had thought to look at again in v.4, but given the way you have explained that it works, Neon, it's not worth looking -- it will never run fast on any computer I own. It's engineers gone mad. Like the xkcd.com cartoon attached!

By the way, I had it working with JPEGs and TIFFS; it was very slow with those too. I'm on a 2010 13" MacBook Pro 2.66 GHz.

I've actually given up on it. Back to iPhoto 09 I go (not 11; they fouled up the interface), with multiple libraries managed by iPhoto Buddy (a much more user-friendly management system then Aperture's) using PhotoLine as my external editor as I did before Aperture and with Aperture.

Is PhotoLine's repair brush better than Aperture's? In that it works in a flash, yes! In other respects? Seems to me that Aperture's repair brush is a total klutz, but I have to say I really don't understand it; I didn't bother spending any time with it since it (like so much else about Aperture) didn't work in expected ways. I just tried it, as a matter of interest, but when you have to sit there for significant time to see a fix appear ... When I wanted to do serious editing, I went into PL as external editor to do it. And then there is the news of the much improved repair brush in the current PL beta ...

Cheers, geoff

Geoffrey Heard
Business & Environment Writer, Editor, Publisher
The Worsley Press

[greenmorpher]

An update -- gue of Typinator has been tackling the problem and seems to have made progress. However, running his latest beta I still get a delay of around 10 seconds (formerly 25-30+ seconds) in PLs copying and pasting action while Typinator is running. When Typinator is not running, PL's copying and pasting of the large picture file I am using for testing, is virtually instantaneous.

Cheers, geoff

[greenmorpher]

Returning to my original post:

All fixed. Gue has just released a beta of Typinator that works perfectly with PL -- no more interference when PL is copying and pasting.

Cheers, geoff

Geoffrey Heard
Business & Environment Writer, Editor, Publisher
The Worsley Press