My observations:
There are 3 things slowing me down. 2 are mentioned in this post.
1. Clouds / Weather
2. Cars
3. Objects

I have also noticed that my graphics card may not be able to “handle” the fill rate.
I have adjusted options such as trees, etc. I have not noticed much of a difference in performance with these ON/OFF. I also, have 8 AI planes on, which I have tried toggling, with no performance issues. I believe objects is one of the main killers here. I have also noticed, that the utilization of my resources is not close to full (36% of my graphics card and 16% of my CPU, heh). Also, I have noticed that X-Plane is not giving jobs to all of my cores, as some are not in use AT ALL. I am pretty sure that this may be due to a problem within OpenGL, as I have noticed this problem with other OpenGL based games, however, I hope there is possibly a way to bypass such a limitation. Also, as Ben has stated in his post, I believe the fill rate does need to be optimized in X-Plane 10.
Those are my current observations. I will be observing more into this issue in the future. Also, something to note, is that while observing, I am using the BETA CCC driver 12.4, which I did forget to mention above. Also, I do have a question if anyone here is a graphical guru, would it be possible to give jobs to each graphics card to do, instead of having them generate every other frame, while in crossfire?
Also, one more thing I forgot to add above about the objects, is that I have not determined whether these are graphical-based or cpu-based, or both.

With that said, I will conclude my brief observations.

See the link to hacksoflife in the post – glMapBuffer isn’t so fast, and the AMD pinned memory makes it moot.

So the most interesting bit is missing, what API is this all about, and which one is faster ?

PhM

I think it would be very useful (many devs do it), to actually make a program that extracts needed info (possibly to a text file so that user know that nothing personal is retrieved) in a uniform way, so that interesting statisics can be extracted.
OS is vital, CPU type also, GPU(s), RAM size and speed, disk sizes, network capabilities.
It would be interesting to know if you still develop (and “drive around obstacles”) for a limitation for customers that represent maybe 0,5% of your base. Or that you don’t actually make use of something 90% of your users already have.

Anyway, you know better.

Someone buy that man a bigger monitor! A nice 30″ 2560×1600.

– CK.

Only the OS split and 32-64 bit split mentioned previously – we can infer that the 64-bit folks have 64 bit CPUs. We do not currently have a GPU or memory survey.

I’m trying hard too, maybe something having to do with Windows? x64 philosophy? No. I don’t get it.

As already mentioned, nice article Ben, looking forward to seeing more of this detailed info about core features/problems etc. Some relevant develeper screenshots/illustratuions would be nice to have too. They really make difficult things easier to understand!

This leads me to another question… Do you have any good hardware stats of your user base? (and is it publishable? why wouldn’t it be)

I am laughing now in front of my monitor. 😀
A spike of stupidity (for an otherwise quite intelligent person). 😉
Mistook XP for the Windows version instead of X-Plane short. 😛
Hahaha sorry.