On Thu, Nov 07, 2002 at 08:58:40PM -0500, Dave Bauer wrote: > > I think the only thing I'm still hung up on is arrays. In PHP it was > > ultra-easy to handle database rows using associative arrays,, and > > handling large numbers of rows in multi-dimensional arrays. I don't > > really know how to emulate that in Tcl, without setting up a separate > > API to handle it. Anyone have some tips on that? > > Take a look at ns_set > > http://www.aolserver.com/docs/devel/tcl/api/general.html#ns_set
If you have a lot of data - hundreds rather than just one row - using an ns_set is a bad choice, as they are implemented as linearly searched C arrays. This gets very slow for large datasets. If you create a huge ns_set (say, in some custom C code), it can be MUCH faster to immediately convert it to a Tcl array or AOLserver nsv before further processing in your Tcl code, rather than using the ns_set directly - if you do lots of key lookups, it definitely will be. I know, I tested it. (And in fact, I left it that way, as I never did sit down and figure out how to create and populate a Tcl array in C and then hand it to Tcl.) AFAIK it's not mentioned anywhere in the docs, but the uses of ns_sets in AOLserver seem to keep this in mind. E.g., the database API puts ONE row of data into the ns_set, not thousands; AOLserver uses ns_sets for holding HTTP headers because you need to allow duplicate keys, but you're never going to have that many rows. I'd say, use an ns_set when these features are either something you want, or not a problem: - Key order is preserved. - Multiple identical keys are allowed. - Very poor key lookup scalability - slow for large datasets. Otherwise, use something else, probably a Tcl array, maybe an nsv or Tcl list. Oh yeah, and I recomend not using server-wide shared ns_sets either. Doing so is unusual anyway, but I did for a while (on AOLserver 3.3+ad13), and it caused unexplainable memory leaks, even though I was always properly freeing the ns_set -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com
