thnx to matju and item for your answers
it's very good to know all this info. in fact i already made installations, where a pd-patch is running during the whole day (although i believe it is not an issue in this specific case).
i'm still not quite sure if i undesrstand it correctly. are only symbols like array-names, [send]s and [receive]s, [throw~] and [catch~] etc stored in pd's symbol-table (which i assume)? or does also sending a lot of messages and using [route symbol] lead to a pollution of the symbol-table?
if the first case is true, there are maybe some ways to avoid too much pollution. in case of netpd for example it happens that often a bunch of patches are open and each of them uses a lot of send/receive-symbols. now, if i understand it right, using:
[r mysynth] | [route freq amplitude]
causes less pollution than something like this:
[r mysynth-freq]
[r mysynth-amplitude]
is that right? is it also better to use short symbols or doesn't that matter?
roman
On Tue, 14 Feb 2006 07:32:58 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:
On Tue, 14 Feb 2006, Roman Haefeli wrote:
"Mathieu Bouchard" matju@artengine.ca wrote:
$0-send/receive: what would be the difference to a NOT-fake-mechanism?
Avoiding pollution of the symbol-table?
this topic has been mentioned already a few times on this list, but suddenly i still don't know what this means exactly. does pollution mean, that the symbol-table uses a lot of ram? does that have any bad effects on performance? is there a good way to avoid pollution (i mean when patching) ?
Pd starts up with a fixed-size symbol-table. This is a big array of symbols. If the table becomes full (or even just crowded) there are more and more symbols that share the same cell in the symbol-table by chaining one symbol to another. Long chains of symbols are slow. If you use many symbols, the quick fix is to increase the size of the table but to do that you need to recompile pd.
Most of the problem of having many symbols comes from the fact that most symbols have two parts, because they're made like $0-foo where $0 is some integer. There's no quick escape from that. Pd needs a new atom type for local symbols. When it gets it, all externals would have to be updated in order to support it.
The other main cause of symbol pollution is that pd doesn't have text strings. Strings can be deallocated, while symbols are æternal, that is, until you quit pd. If you use pd for heavy string processing in an art installation, make sure you do scheduled shutdowns in order to prevent swapping, thrashing and crashing; make tests and extrapolations to figure out when it would have used all of your RAM, etc.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada