[Openal] OpenAL 1.1 (OS X) alGenBuffers problem

[E. Wing]

So your Shark profile made me curious about what's going on. First, in
my personal experiences with gcc (including 4.0.1), it's not the
speediest of things especially when it comes to the STL. I've seen it
do incredibly stupid things. I once had a bit of code that was in
milliseconds on Visual Studio 7.1, but took about 2 minutes on gcc.
Fortunately, Shark was such a great tool, I managed to retool the code
in about 10 iterations so it was about par with Visual Studio.

Anyway, looking at the source code for GetSourceByIndex (pulled from
svn today), it looks like the OALSourceMap is a std::multimap. I
haven't dealt with multimaps much in STL, but I do recall short stints
where they did not seem particularly speedy.

Second, it looks like GetSourceByIndex is mostly a for-loop that
increments through all integer values in linear order until it finds
the value it wants. It iterates an iterator on each pass to keep in in
sync with the integer index. I don't think this is terribly efficient.

So there are probably much better ways to implement this. With some
thought, this could be done with a map or hash_map lookup which could
result in a much faster lookup. Also, the code increments the iterator
in the iter++ fashion instead of ++iter. The post-increment version is
slower than the pre-increment because C++ dictates that a temporary
object must be created. Combined with the fact that this is a multimap
iterator which may not be terribly fast to begin with, I suspect the
iter++ operation is really slow. In the way it is used, I think this
could be changed to a preincrement style. I'm also thinking
const_iterators might work here too, but I don't know if gcc gives any
performance benefits for using const qualifiers. (Probably not).

Anyway, the easiest thing you could try first is modify the source to
change the post-increment operators to pre-increment operators and see
what your performance looks like. You might see if you can use a
const_iterator and check performance. These are the two really easy
things to do. If you do these, I would love to hear what the
performance stats look like.

After that, I think we need to look at storing the source/index
relationships in maps or hash_maps instead of doing linear searches
which will require some redesign. (I kind of thought this is what a
multimap might already give you, so maybe this is what we need to look
at first. If not, my gut says to also get off multimaps which might be
possible with other changes to keep source/index relationships in
other maps.)

So I would love to hear Bob Aron chime in on this. (Perhaps we should
all file a performance bug report on the Apple radar so he has to look
at this :)

Thanks,
Eric


> Here's the output from Shark, using a bottom up view of the call tree:
>
> 	67.9%	67.9%	OpenAL	std::_Rb_tree_base_iterator::_M_increment()	
> 	0.0%	67.7%	OpenAL		OALSourceMap::GetSourceByIndex(unsigned long)	
> 	0.0%	34.2%	OpenAL			OALContext::RemoveSource(unsigned)	
> 	0.0%	34.2%	OpenAL				alDeleteSources	
> 	0.0%	34.2%	ww						audio_stop(int)	
> 	0.0%	33.6%	OpenAL			OALContext::AddSource(unsigned)	
> 	0.0%	33.6%	OpenAL				alGenSources	
> 	0.0%	33.6%	ww						audio_playasset(int, int, t_audioasset*)	
> 	0.0%	0.1%	OpenAL		OALContext::CleanUpDeadSourceList()	
> 	0.0%	0.0%	OpenAL		OALContext::SetListenerVelocity(float, float, float)	
>
> So what this is saying is that my app's two audio functions are
> taking nearly 68% of the CPU time (audio_stop() - 34.2% and
> audio_playasset() - 33.6%). But all that time is actually spent
> inside OpenAL, ultimately in the same call,
> OALSourceMap::GetSourceByIndex(), which in turn is spending all it's
> time calling std::_RB_tree_base_iterator::_M_increment().
>
> It seems to me that either the standard iterator is very inefficient
> (the app is compiled with gcc 4.0.1 apple-powerpc-darwin), or that
> there are a lot of buffers being iterated. It's also possible I
> suppose that the logic is just wrong somewhere, resulting in too many
> calls to OAL::GetSourceByIndex()
>
> BTW, the buffer numbers are largely sequential: 2401, 2403, 2404,
> 2405, 2406, 2407, 2408, 2409, 2411, 2413, 2414, etc...
>