Lion Preview high CPU behavior with PDFs

The problem seems to be related to Lion's versions feature and gets worse if your recently opened images are very large files.

The fix is to go to Preview / File / Open Recent and select Clear Menu before quitting Preview and/or restarting your Mac.

Doing so will make Preview as snappy as it used to be before Lion's versions. /e/

The only working solution I have found so far:

Let go of Preview. Move on to Adobe Acrobat Reader.

Same problem, so it hasn't been fixed with the latest system updates. My Pdf's are tiny (around 3 to 5Mb) and still Preview is becoming at best unresponsive and at worst, crashes! What is weird though is that this problem is recent, ie it didn't coincide with the installation of Snow Leopard, but much later.

Anywya, if anyone has any solutions, I'm open to suggestions.

Cheers,

oh, I forgot to mention the fact that if I open a pdf created by someone else, let's say around the 3Mb mark, and if I add comments to it via the annotations feature in Preview, when I save it, it becomes around 10 times bigger (around 30Mb). Then if I try to reduce it's size with the quatrz filter, it then gets as big as 300Mb!!!!

I would have swithcecd to Acrobat Pro long ago if I had it.

Cheers,

baseline... Mac Mini 2010 5400rpm HD, 8GB

Mavericks 10.9.1

14MB OCRed/Indexed scanned document

I'd see several minutes199% CPU spikes, and several minutes of response delay for navigating the 14MB document, especially using search and/or thumbnails.

As noted in a previous note in the thread, I deleted the

~/Library/Application Support/Preview/PDFIndex4.sk

After this, I force quited Preview, and restarted it. Still had a lot of slowness, revolving around an OCRed and indexed file (manual for an electronics component).

This did not help much. At no point has this file recreated itself, so I don't think it is in use by Preview in Mavericks.

So, I let Preview plow through the file to open it... Before doing anything else, I then saved it with a 'reduce file size' quartz filter.

I ended up with a file that was actually LARGER than the original (14.1->19.1MB)

Now, when I search the file, (and this was the trigger event), I notice that it still spikes during the first search (likely searching all the binary for the target, and taking the time building up an internal hash table for subsequent searches), but

a) it finishes the first search MUCH Faster),

b) subsequent searches are much faster and much lower in CPU impact

c) and uses less private memory.

YMMV, but this has fixed my problem

My guess is that the output of whatever created the PDF was in a format that confused the navigational/search tools of preview (my guess... the file was compressed in a format that was 'readable' but required constant decompressing during search/navigation/thumbnail display) . saving the document out into a more apple-happy format likely made all subseque

The problem appears to be related to preview search indexes. Rather than just delete PDFIndex4.sk, I deleted all the files in and below

~/Library/Containers/com.apple.Preview/Data/Library/Application Support/Preview/

I also removed all the directories under SearchIndexes. Once I did this, I started preview. This stopped my 110% cpu usage. Not sure for how long this will stay 'fixed' though. For grins, I also deleted the files in

~/Library/Containers/com.apple.Preview/Data/Library/Caches/com.apple.Preview

No more maxed out CPU for now.