[PD] httpget: fun with tcpclient and pdstring

[Martin Peach]

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