To further clarify, I'm not having issues with the sliders. What I was describing is that if I grab the slider and yank it as fast as I can from -4 exposure compensation to +4 compensation, I can start to see individual screen redraws as the image moves from underexposed to overexposed. I'm not getting a perfect 30fps "video fade transition" as it moves through the process, but instead get a rapid flicker of redraws. I wouldn't expect any computer to be able to render the RAW data that fast at this resolution.
In normal usage, the sliders work just fine.
Interesting, I read your post and thought I'd try that with the exposure slider. To give a bit of background I've never actually measured the rendering time on my system as I have no complaints with the performance. I opened an image that I haven't previously had in the develop module, although upon import I do have a base set of adjustments applied (including sharpening and noise reduction). Loading the image in develop took something less but very close to a full a second, with the second screen actually instantly showing the image Once loaded I "yanked" the exposure slider from -5.0 to 5.0 several times. Too quick to measure the time of the "yank" but probably .10 seconds less? The effect on the screen was almost as immediate, maybe another .10 second at most. My second screen was slightly behind the first, but the whole process with both screens is far less than a second and very smooth.
Okay, for my system, the largest time bottleneck seems to be when moving from image to image if, and more so if the image has not been previously loaded in the develop module. It's not a large one but it's there. So what hardware resource is being used for that particular function? I opened the resource monitor to take a look while moving around. The only truly significant action I see happening is processor usage. It jumps from a baseline of approximately 4% usage to a range somewhere between 45-55% usage as I move from one image to another. You also see a bit of disk read but frankly it is just a blip and never registers as a percentage in the monitor. Same with memory.
This leads me to believe what as has been written multiple times, that Lr is very processor intensive which makes a tremendous amount of sense to me and always has. We know that the develop module stores a basic preview of an image in the cache after the first use. having basically nothing but the de-mosaicing performed. All other adjustments applied to the image have to be rendered each time the image is accessed. That takes processing power. The image appears on screen instantly, but the "loading" message hangs around till the processor has completed this rendering task.
For me personally, it would appear that the only way I would see faster performance is by increasing processor performance. If I did so, I might eventually see a bottle-neck elsewhere but from the basic monitoring I've done thus far I have a pretty big window before that happens.
What about the people that are having significant performance issues now? Especially those that are reportedly running more powerful processors than mine? (i7-930 overclocked to 4ghz). Most of the complaints I've read have been about rendering time and/or smooth operation of adjustment sliders. For the most part the complaints are from those that were running Lr3 just fine. We know there were significant changes to the process versions, some of those very complicated, between the versions of Lr. If we believe these differences and issues to be processor path related then perhaps processor/memory transfer speed or memory speed itself comes into play? Although I haven't done the math that seems unlikely to me but who knows. FWIW I'm running 12gb DDR3 1300mhz memory overclocked to ~1550 mhz.
Since my disk system is all based on 7200 rpm drives I'm having a hard time thinking that these issues have anything to do with disk access. I'm set up with the operating system (Win 7 64), Lr software, the catalog, as well as the previews on one disk. The Lr Raw Cache is on another single disk. The images themselves are on a 4 disk array in Raid 10.
**I see the same basic performance whether I'm working on 12mp 5D files, 21mp 5DII files, or scanned Tiffs at over 200mb in size. Someone pointed out to me that my huge film scans aren't the same thing as a RAW file of the same size primarily due to the de-mosaicing needed with the digital capture. I understand how that can make a difference on the initial rendering in develop but once the cache preview is generated (which includes de-mosaicing for the digital file) the differences between the two should be minimal I would think. All other Lr adjustments have to be performed each time for each type of image to my knowledge.
Also, I ran the above tests on my system as I normally use it, meaning I have a browser open with 7 or so tabs, TOPO software, Outlook, Excel, and Quicken financial software running (but idle) at the same time.
