Tuesday, June 10, 2008

Sharing is a bad thing

I took a bit of time out to do some performance testing, partly avoiding procedural cities as I haven't a clue how to go forward but mainly to see what could cause my planet to be so slow when rendering a pretty low amount of polys.  I created a new project and ran some tests to get a benchmark, here are results for one patch getting larger as time goes on:

 performanceFpsSucksForSharedBuffer

Sharing the one vertex buffer is pretty much worse than having no vertex buffer at all!  I tried to see if 50 objects each with their own buffers vs. each sharing the one buffer would make any difference, but nope:

performanceFpsSucksFor50ObjectsWithSharedBuffer 

Weirdly enough though, 75% of all pie-charts look like pac-man:

Creating and deleting buffers on the fly for the planet just won't work as I found with earlier experiments with quadtrees.  Although I did find out that the garbage collector can't clean up buffers because behind the scenes a load of events are hooked up and these all have references to the buffer.  Setting Device.IsUsingEventHandlers to false can turn this off.

Sharing isn't efficient either.  A bunch of buffers will have to be created on startup to be exclusively used by each patch.  Working out how many and what size will be another performance analysis job... is it simple enough that I can keep procrastinating procedural cities? ... probably not.

No comments: