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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list