i worked on a project for years that used a format equivalent to XML or ASN.1, but we thought simplier.
naming the entities presented no efficiency problems for us. i spent 6 months in several stints profiling that system and for a 10k result set, the tcp overhead was greater than the packing and unpacking overhead, but neither represented 1% of the runtime of any end-to-end process that i looked at. with the exception of word processors, web browsers, and maybe gcc i do not agree with your corollary to moore's law. 15 years ago i was stuck with sun 160s and vaxen. 10 years ago i had a ibm rs/6000 41t and a 66mhz pentium II. i'm still not up-to-date, but by all my performance metrics, the 997mhz system i use now is *way* faster. i've even got a better internet connection via dialup than the sun/vax setup did in the late 80s. - erik On Sat Feb 11 02:24:26 CST 2006, [EMAIL PROTECTED] wrote: > > So why not /lib/ndb format: textual attribute=value pairs > > with grouping? > > Because (a) they are language/alphabet specific and (b) they are > inefficient. > > Before you jump down my throat, I am aware that the inefficiencies > smack of premature optimisation, but in ASN.1 days they were mere > failures of vision. And I do maintain that saving processor cycles > and storage is not a futile quest. The corollary to Moore's Law is > "Software bloat exceeds any gains in processor performance even before > such gains can be exploited".
