Re: ASN.1 (Was: [9fans] More 'Sam I am')

[quanstro@quanstro.net]

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, lucio@proxima.alt.za 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".