[Clam-devel] Sample by Sample Processing in Network Editor

[Xavier Amatriain]

On Thu, 2006-12-21 at 19:33 +0100, Pau Arumi wrote:
> my first thought is that we really need to integrate this 
> development/experiments into subversion.
> why not to have simple proof-of-concept networks and do all 
> infrastructure changes in svn.
> the benefits are clear:
> - you provide use cases for pushing development and research
> - we can help much more in your use cases

This would be great. I think that CLAM does need to offer at least a
minimal infrastructure for sample-by-sample processing. There are a few
minor problems though. First, most of the processings I am using are
so specific to this app that it would make no sense to add them to
the repository. So I will have to create
a dummy network with some general-purpose processings (no biggie). Also
this requires modifying the default Network policy to Blocking and using
RtAudio instead of PortAudio so this is something I am not sure you want
to go back to.

If you think it would be interesting as I said adding a couple of
processings and the network is simple but what about the other issue?
Add a few defines here and there?

> 1. redrawing methods depend on timers (since NetEdit4) and it's not
done 
> on Do basis. what are the synthoms?

I am profiling with Rational Quantify on Windows and I see the Graphics
thread consuming more time than the processing one. Functions like
PortWire::draw were called on the order of 2x times the Do was called
(12000 vs. 5000 for instance). I am saying "were" because in the latest
profile runs that I have just done I am not seeing this behavior (weird,
I will report on this later but I am thinking that this might not the
issue).

> 2. i think it could be more efficient if we get rid of 
> different-port-size matching. but more in a policy way than a TData 
> specialiation. but lets analyse first the situation.
> are you compiling in release? all regions related checkings are done
(or 
> should) only in debug and they are expensive.  apart from checkings
what 
> operations of produce() and consume() are expensive? have you done
any 
> profiling?

Hey, who do you think you are talking to? I am the master of
profiling ;) So, yes, I am running with full optimizations active and
the problem is not in the debug checkings. Just so you have an idea,
here is one of the most expensive operations:

WritingRegion::Produce

(and inside of it the SreamImpl::RegionHasAdvanced and
PhantomBuffer::Touch)



-- 

/*********************************
 *       Xavier Amatriain        *
 *  Associate Director - MATi    *
 *  Research Director - CREATE   *
 *    UCSB, Santa Barbara CA     *
 *      1-(805)- 893 83 52       *
 ********************************/