Yes, I did load factory settings before.

However, I just figured out that the actual error description should have been different: After loading the file, the problem occurs directly when switching to rendered mode. It takes that long until the render result appears. That switching back to solid mode is slow is only a consequence but not the actual problem.

As you can see: 41.8 seconds. However, it takes about 41 seconds until it even starts rendering.

Just tried it inside VirtualBox (Win7/64, VBox graphics driver): same problem (but takes over 1 minute til response)

I'm gonna attach WinDbg and see what Blender is doing all the time. Will let you know whether I can figure it out.

Result from WinDbg:
Multiple times I breaked into the running process, and the callstacks of the busy thread was (two examples):

blender+0x3d1fda
blender+0x3d23a1
blender+0x3d5682
blender+0x18f997
blender+0x22abf
pthreadVC2+0x5ce5
pthreadVC2+0x9437
pthreadVC2+0x94eb
kernel32+0x1652d
ntdll!RtlUserThreadStart+0x1d

blender+0x3d1f2d
blender+0x3d23a1
blender+0x3d5682
blender+0x18f997
blender+0x22abf
pthreadVC2!sched_get_priority_max+0x49e8
pthreadVC2!sched_get_priority_max+0x813a
pthreadVC2!sched_get_priority_max+0x81ee
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

So I guess it's related to "blender-2.70-windows64\pthreadVC2.dll" (Description says: "POSIX Threads for Windows LPGL"). I hope this leads to the right direction if you can reproduce it somehow.

Thanks for looking into it.

Sorry Sergey, but that was the best I could provide. Didn't have a debug build with debug symbols....

Kind of found the reason myself: After reducing the test file more and more, there was nothing left but a simple sphere with no modifiers and material. But the problem persisted.

In the end, it was the tile size: It was 8x8. Increasing it (to 16x16 or higher) before switching to rendered view considerably reduces Blender's response time. Note that my viewport size is ~1632x1286, and the small tile size resulted in a lot of tiles. Reducing viewport size and keeping tile size at 8x8 consequently also reduced response time. Dunno why this leads to Blender not responding anymore for such a long time - but that's your part now. ;-)

I was looking at this bug ticket and I tested the above attached sample file for Blender Internal with the current official release of Blender 2.71 (Hash: 9337574) but I couldn't notice any really abnormal delay in the refresh time of the image being displayed on screen switching back and forth from Solid to Rendered view mode, even with complex scenes.

Testing platform: Mobile Intel Core i7 720QM (1.66GHz), Win7 Pro 64bit, 8GB RAM, NVIDIA GTS 360M with 1GB VRAM; Blender 2.71.0 64bit (Hash: 9337574) (blender-2.71-9337574-win64.zip)

The issue reported can't be reproduced so far, and has been moved to the BF Blender: Unconfirmed project.
If 2 other people aren't able to redo the bug after 2 weeks, it will be closed.

We appreciate the effort that goes into making bug reports, but to be able to fix bugs we have to be able to redo them.
If there is anything you can provide to help others to reproduce the problem, be sure to include it.

I've already considered this solved because changing tile size from 8x8 to 16x16 or greater made the problem disappear.

Verifying it now again, the problem (i.e. at 8x8 tile size) must have been fixed - maybe "accidently " - somewhere between blender-2.71-6443bfd-win64 and blender-2.71-dbc79e7-win64 because the later one doesn't show it anymore. Latest build is also ok. So, can be closed.

Thanks once more for your support in any case, i.e. in all cases. :)