Performance
Aperture: Speed Up Aperture By Rebuilding The Database Index
2007-03-04
Everyone is excited about the discovery of using the sqlite vacuum command to rebuild the index for Mail.app. Well the same trick works for Aperture. Rebuilding the library database indexes is much faster than rebuilding the entire database. While probably not as effective, it does improve the speed of Aperture, especially for heavily-used libraries with a lot of deleted images. [Update: Aperture 2.0 has two databases: the Aperture.apdb database and a new one called BigBlogs.apdb. As currently written, this script does not touch the BigBlobs database.]
Here is the script. You can download a ZIPped version from the download page or paste the text below into Script Editor. Be careful of the single- and double-quotes getting modified in the process. They are all straight quotes. [Update: I added an improvement sent to me by Adam Tow. The script now only opens bundles and defaults to the Pictures folder.]
tell application "Aperture" to quit
set new_file to choose file with prompt "Select Aperture Libary to compact its database" default location (path to pictures folder) of type {"BNDL"}
set libname to (POSIX path of new_file) & "Aperture.aplib/"
set dbname to libname & "Library.apdb"
set sizeBefore to do shell script "ls -lah " & (quoted form of libname) & " | grep -E 'Library.apdb$' | awk {'print $5'}"
do shell script "/usr/bin/sqlite3 " & (quoted form of dbname) & " vacuum"
set sizeAfter to do shell script "ls -lah " & (quoted form of libname) & " | grep -E 'Library.apdb$' | awk {'print $5'}"
display dialog ("Database before: " & sizeBefore & return & "Database after: " & sizeAfter & return & return & "Now try it out!")
After prompting to select an Aperture library, it runs for a while (up to a minute on large libraries) and then shows a dialog box comparing the size of the library database before and after processing:
Let me know how much it helps.
|
Aperture 1.5.1 On The 24 Inch iMac
2006-11-22
Here are some more observations from running Aperture on the 24" Core 2 Duo iMac for a few days.
Importing is very fast. I think it is faster than the roughly four times speed up I have been seeing in other areas. I plug in my card into the reader and the image thumbnails fly onto the screen at a rate of twenty a second or so. This is probably not all Aperture: it could be just that USB is faster on this machine. Once I press the Import button they are copied into the library at about four times the speed of my G5 iMac, appearing in groups of about twenty. Previously only four or five would appear at the same time.
In full screen mode or if I click on the image in the viewer the scroll ball on the Mighty Mouse flicks through images instantly as I roll it up and down. If I stop, there is about a second before the full-resolution image appears.
Straightening images is still slow, but not as slow as with the G5. If I add adjustments and then straighten it is very slow, so I think I will be straightening first.
A smart album that filters the entire library of 20,000 images takes about 6 seconds to fill the screen with thumbnails. Pressing F to go to full screen takes a second or less.
Creating a web gallery from 335 images takes about three seconds. A smart album of 70 rejects for the whole library appears immediately. It takes about 8 seconds to delete all of them. And album of 660 images takes about two seconds to appear. Books take about two seconds to appear. Autostacking is now usable, stacking in real time and taking about two seconds to fully display all the images.
Zooming on images is limited to five, the same as my G5 iMac.
A full text search for the word "hello" on 20,000 images takes about 38 seconds to return an empty result. Doing the same thing with a limited search for the word "keep" returns three images in four seconds. That big difference is because the full-text search is linear, while the limited search uses the database.
Importing is very fast. I think it is faster than the roughly four times speed up I have been seeing in other areas. I plug in my card into the reader and the image thumbnails fly onto the screen at a rate of twenty a second or so. This is probably not all Aperture: it could be just that USB is faster on this machine. Once I press the Import button they are copied into the library at about four times the speed of my G5 iMac, appearing in groups of about twenty. Previously only four or five would appear at the same time.
In full screen mode or if I click on the image in the viewer the scroll ball on the Mighty Mouse flicks through images instantly as I roll it up and down. If I stop, there is about a second before the full-resolution image appears.
Straightening images is still slow, but not as slow as with the G5. If I add adjustments and then straighten it is very slow, so I think I will be straightening first.
A smart album that filters the entire library of 20,000 images takes about 6 seconds to fill the screen with thumbnails. Pressing F to go to full screen takes a second or less.
Creating a web gallery from 335 images takes about three seconds. A smart album of 70 rejects for the whole library appears immediately. It takes about 8 seconds to delete all of them. And album of 660 images takes about two seconds to appear. Books take about two seconds to appear. Autostacking is now usable, stacking in real time and taking about two seconds to fully display all the images.
Zooming on images is limited to five, the same as my G5 iMac.
A full text search for the word "hello" on 20,000 images takes about 38 seconds to return an empty result. Doing the same thing with a limited search for the word "keep" returns three images in four seconds. That big difference is because the full-text search is linear, while the limited search uses the database.
This is Why Aperture Uses the GPU
2006-11-10
An article at Wired News explains how raw processing power is moving to the Graphics Processing Unit (GPU). For Aperture and for the Mac in general this is good news: image processing is handled by the GPU where ever possible and increasingly any parallelizable math will be too. Future hardware will see tremendous gains in performance beyond CPU speed increases.
There is a technical article about NVidia's Geforce 8800 at EETimes. The design of graphics processors has moved from being hard-coded to configurable to programmable to now to fully programmable -- a C compiler is available. At 681 million transistors it is one of the largest chips ever made, bigger than the biggest CPUs by several times.
Aperture Performance
2006-11-09
Two recent articles related to performance:
Bare Feats stacks three Macs in a total of five configurations against each other. The tests they run are Lift and Stamp, Remove Adjustments, and Export Web Log. Check back at Bear Feats for more articles.
Adam Tow delves into the guts of Core Data and the SQLite database that underlies the organization of the Aperture database. He has some theories and discussion about the spinning pizza of death we have seen so often with Aperture.
Bare Feats stacks three Macs in a total of five configurations against each other. The tests they run are Lift and Stamp, Remove Adjustments, and Export Web Log. Check back at Bear Feats for more articles.
Adam Tow delves into the guts of Core Data and the SQLite database that underlies the organization of the Aperture database. He has some theories and discussion about the spinning pizza of death we have seen so often with Aperture.
Aperture 1.5: Speed Impressions
2006-10-12
Some impressions of the speed of Aperture 1.5. On my lowly iMac G5 Rev B 2GHz 2GB Aperture 1.5 is faster. Two things are obviously faster to me: displaying thumbnails, and bringing up the filter dialog.
But more than just being faster it is more consistently fast. Dropping into full screen is now smooth. Scrolling thumbnails moves like I would expect it to. Scrolling around zoomed images just happens.
Adjustments are still slow, but not glacially slow. Crop and straighten are jerky. Shadows and Highlights take a while. But all that is expected because my machine has a very basic graphics chip.
But the new loupe helps this now. By setting the loupe on the image and making adjustments, I can watch the image in the loupe change much faster than if adjusting the whole image. When I stop adjusting, the change is fully applied. That's a nice touch for those with low-spec machines.
Filters, especially those with keywords are faster. The only thing I have found that is slower is quitting: it takes time to write out information about the previews. Aperture is tough to benchmark -- just about the only thing that can be reasonably measured is image export and that is dependent on so many non-Aperture things it is hard to use any numbers sensibly. So all we have to go on are our impressions.
But more than just being faster it is more consistently fast. Dropping into full screen is now smooth. Scrolling thumbnails moves like I would expect it to. Scrolling around zoomed images just happens.
Adjustments are still slow, but not glacially slow. Crop and straighten are jerky. Shadows and Highlights take a while. But all that is expected because my machine has a very basic graphics chip.
But the new loupe helps this now. By setting the loupe on the image and making adjustments, I can watch the image in the loupe change much faster than if adjusting the whole image. When I stop adjusting, the change is fully applied. That's a nice touch for those with low-spec machines.
Filters, especially those with keywords are faster. The only thing I have found that is slower is quitting: it takes time to write out information about the previews. Aperture is tough to benchmark -- just about the only thing that can be reasonably measured is image export and that is dependent on so many non-Aperture things it is hard to use any numbers sensibly. So all we have to go on are our impressions.
Speed Up Aperture A Little
2006-06-25
A simple way I have found to speed up Aperture for many operations is simply to work with smaller projects. So I have an Import project and import only into that. After the images have been processed (culled, rated, keyworded, etc.) I then select all of them and drag them to my month project. That moves the Masters to the month project.
Within the Import project I can filter by import session to make the number of images more manageable. The speed-up of a smaller project is quite noticeable: much less spinning cursor and other delay.
Within the Import project I can filter by import session to make the number of images more manageable. The speed-up of a smaller project is quite noticeable: much less spinning cursor and other delay.
Minimize Rapidweaver Image Storage
2006-06-12
While making this blog using RapidWeaver 3.2.1, I have found that the site document gets large very quickly as I add images. This is because RapidWeaver stores all the text and all the images in one large site document rather than externally in pieces in a file structure.
So if I drag in a 3MB TIFF image and scale it in RapidWeaver to 30% of its size, the site document stores the whole 3MB, while creating a much smaller JPEG to upload. To reduce storage requirement this without any extra tools I have found that I can use RapidWeaver itself to do the image conversion. It works like this:
1. Create a blog entry and drag in images
2. Use the image inspector to scale each of them
3. Preview the blog entry and tweak until it is OK
4. For each image, drag it out of the blog Preview and onto the desk top
5. Delete each image in the blog, replacing it with the desktop version by dragging
6. Delete the desktop images
So now the blog has just the JPGs. They are just the right size, and take up minimum space.
RapidWeaver should have a right-click menu that gives the option of doing all of this in one.
So if I drag in a 3MB TIFF image and scale it in RapidWeaver to 30% of its size, the site document stores the whole 3MB, while creating a much smaller JPEG to upload. To reduce storage requirement this without any extra tools I have found that I can use RapidWeaver itself to do the image conversion. It works like this:
1. Create a blog entry and drag in images
2. Use the image inspector to scale each of them
3. Preview the blog entry and tweak until it is OK
4. For each image, drag it out of the blog Preview and onto the desk top
5. Delete each image in the blog, replacing it with the desktop version by dragging
6. Delete the desktop images
So now the blog has just the JPGs. They are just the right size, and take up minimum space.
RapidWeaver should have a right-click menu that gives the option of doing all of this in one.
The Bagelturf site welcomes Donations of any size