On Tue, Oct 9, 2012 at 7:49 PM, Jeff Rogers <dv...@diphi.com> wrote: > I don't know that people love it so much as that there is no exact > replacement for the functionality. > > I'm a big proponent of compatibility but shared sets as they previously > existed are problematic. I wouldn't be at all surprised if they are > thread-unsafe to the point of being able to crash the server. > > An alternative might be to provide equivalent functionality > (order-preserving, multiple entries for keys, access by index or key or > case-insensitive key) as a new nsv subcommand, perhaps 'nsv_multiset'.
Hmm, sounds a bit like reintroducing the old code under a new name. I think people are just unwilling to change old code, not specifically looking for case-folding multi-sets. > Separately, I was experimenting with a performance enhancement to > ns_sets, creating a hashtable mapping the keys to indexes. There is a > slight cost in memory and on the first lookup, but it should get to > breakeven after only around 3 lookups on average, with decreasing > amortized cost after that. The difference is measurable and can be > significant, as much as 4x faster on a large set. However, that's > measured on a very large set, 1000 keys; and the real savings is pretty > small, around 15 microseconds per lookup on average hardware. Is that > kind of micro-optimization worth the additional complexity? Sets are used in a few core places where this sounds like a disadvantage: - http headers (in/out) - html forms - database rows All low numbers of rows with few lookups. Even config values rarely have huge numbers of elements, or duplicates, and often are looked up only once at startup and then stashed away in a struct. How are you planing to use these key/value structures? If you're going to use them from a Tcl API within one interp then you can use the Tcl object shimmering technique. If you make the lookup key fully describe the value instead of using a two-part array-key then after the first lookup you can store a pointer to the value in the spare Tcl_Obj ptr. You can see this technique used in the arg parsing machinery. If you're sharing between interps you can't use that technique, but there may be other things you can speed up. For example, here's a project I never finished to create an API identical to Tcl hash tables except that you can pre-allocate space for the value in the key struct: https://bitbucket.org/groks/naviserver-nshash The idea was to reduce memory fragmentation and be more cache friendly, which gets more important as modern computers with numa memory layouts and a large difference between cpu-memory speeds. There's also this r/w config replacement: https://bitbucket.org/naviserver/nsconfigrw which has links to some discussion about implementation, including support for multiple values, case folding etc. Or maybe you're trying to recreate PHP's do-everything hash-list container... :-) ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
