[Openal] OpenAL 1.1 (OS X) alGenBuffers problem

[Bob Aron]

Eric,

As usual, a thorough evaluation on your part, thanks. I think you  
have some valid points here and I would
definitely recommend writing a bug to Apple on this so we can track  
this. It would be helpful if whoever
does write the bug to provide all this info as well.

-bob
___________________________________________
CoreAudio Team
Apple Computer Inc.
(408) 974-1221
baron at apple.com

On Dec 13, 2006, at 3:57 PM, E. Wing wrote:

> 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...
>>
> _______________________________________________
> Openal mailing list
> Openal at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal



_
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20061213/e23c5e53/attachment-0001.html