On 09.10.12 22:43, Stephen Deasey wrote: > >> 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. also, in our experience ns_sets are typically quite small.
Since the ns_sets are currently used just per thread, the question is for what kind of purposes needing large amounts of keys are these used. Tcl has already arrays and dicts. Handling multiple values per key can be realized with "dict lappend". -gustaf neumann ------------------------------------------------------------------------------ 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
