[RTcmix-discuss] more memory issues

Douglas Scott netdscott at netscape.net
Sun Jan 9 23:32:57 EST 2005

Brad Garton <brad at music.columbia.edu> wrote:

>On Sun, 9 Jan 2005, Douglas Scott wrote:
>> That's not the way it works.  You start with a reasonble, average size 
>> as your default, and then grow by factors of 2 when requests come in for 
>> something larger.  
>For PANECHO and DELAY I would be hard-pressed to name a reasonable 
>'average' size -- I use them all over, from very very tiny delays to 20+ 
>second (seriously!) delays.  I also have several apps where I use a large 
>number of them, all with varying delay times.

Yes, but setting the size to something in the middle will not seriously impact us, and it will work for ALL the "tiny" cases, up through any middle-sized case.

>> For example, to match your example, you might have it default to 20 
>> samples, and when the request for 10, 20, came in, all would be well.  
>> When the request for 30 came in, it would resize to 40.  So the request 
>> for 30 would be OK, and so would one for 40.  If it continued to go up, 
>> the resize would double the size each time --- or possibly quadruple it, 
>> to avoid lots of reallocs.
>Using several COMBITs as a chorus-flange type thing would do some serious 
>realloc-hitting in a very short time, I think.  After watching the 
>behavior or the CC5.sco file in real-time, I'm pretty convinced that we 
>need to bee careful about schedule-time allocation.  I literally pushed 
>the 'go' button and waited in excess of 30 seconds before hearing the 
>score once as my machine thrashed memory around. 

But this was not due to reallocating -- this was due to allocating!  I am trying to fix the problem of not wanted to specify the size as an additional argument.  Whether or not memory allocation (all at once or realloc'd) takes a long time is a separate issue.

>> >Another possibility -- which I'm sure you won't like, Doug! -- is to
>> >find out if the pitch (or delay time) PField is a ConstPField.  If so,
>> >size the delay line so that it fits this exactly.  Otherwise, make
>> >a big delay line, like we do currently.
>> >
>> You are correct about my opinion.  All I will add is:  Please dont go 
>> breaking decent object-oriented code until you have proven to me that 
>> the well-coded solutions really are too inefficient to work for you.
>I'm pretty clueless about this -- why does checking the type of something 
>break the object-orientedness?  Isn't that sort of what oeprator 
>overloading does?

Operator overloading lets you perform arithmatic operations (+, -, etc.) on an object which is not a built-in type.  It has nothing to do with checking the type of a class.  Calling operator Something *() on a class to cajole it into saying yay or nay is no different really from adding a function ::AreYouAFoo() to a class.

Regarding why it breaks OOP:  The whole point of this part of our system is that the underlying types of the classes can shift at any time without the Instrument **ever** having to know that anything changed.  *All* PField objects are treated in an identical fashion.  You dont really want me to go on and on about this again, do yeh?  =^\


Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

More information about the RTcmix-discuss mailing list