Mathieu Bouchard wrote:
On Wed, 4 Mar 2009, Martin Peach wrote:
That's nice. Now we need some html parsing objects so the pages go into the patch and not the pd window. It works well if the received pages are loaded into a table. I made tabfind to search a table for a string. Tables seem more efficient than lists and less volatile.
Lists are volatile because they are (typically) stack-allocated or in any way their contract of use makes (argc,argv) only valid during the call... so you could use a heap-allocated argv but modify it between calls and it would still make the list data have a stack-wise accessibility.
Because lists are volatile, they need to be copied by any object that wants to keep them. It's actually worse than that, as objects used recursively have to watch out for what they can deallocate. It's not like you could make [list] be faster without complicating it... and this includes plain data-recursion as well too (set cold-inlet of an object while its cold-inlet has still a job pending on the stack).
Tables can be much faster but they also need to be statically-allocated (or dynamically-patched!), and they are type-restricted (where you can't say that any element slot may contain any atom one decides at runtime), and you have to find names for the tables because they can't be anonymous.
Tables also use half as much memory as lists because they are mainly an array of floats, while a list of floats is actually an array of atoms, each atom comprising a tag indicating that it contains a float as well as the float itself. For the network objects the lists are made of floats so the type restriction is not important. Also a table can be reused and resized and its contents never get added to the symbol list so there's no constantly increasing memory involved. The typical web page has a huge amount of irrelevant text that would quickly clog the symbol table, so it's more efficient to extract the relevant bits before converting any of it to a symbol.
Martin