[e-lang] Being Disheartened by MarkM's Eventual I/O (was: While thinking of operator syntax)

Dan Bornstein e-lang@mail.eros-os.org
Thu, 27 Jun 2002 09:43:40 -0700

I wrote:
>[stuff about asynch i/o in E, a while ago]

Constantine Plotnikov writes:
>You propsal had O(pow(resultSize, 2)) memory allocation cost with
>O(pow(resultSize, 1)) minimal cost {other object could be GC-ed}.
>actually in your sample it will be like  (resultSize * (resultSize /1000))/2

Hrm. My intention was that there would be about O(resultSize) in allocation
for an efficient implementation, with a little overhead for objects that
had to wrap around lower level arrays. I'm not sure how the exponential
comes in to your calculation. (If you meant it because I'm using add on
Strings, then please disregard that; clearly one can do better than that in
a non-toy example. E.g., there's no need to copy the result of a read

I know that even that is too much allocation for some high performance
apps, but I think it fits in the realm of "good enough efficiency for an
easy enough to use abstraction" that E generally goes for.

>Mechanism for E needs to have the same efficience a Java or E will be
>never used in IO applciations.

Careful with your absolutes, there. There is a large class of applications
where this sort of efficiency simply doesn't matter. I know that what I
outlined is plenty good enough for most of my own needs, in particular.

I would put "high efficiency I/O abstraction" on the wish list for E, but
significantly lower than "easy to use I/O abstraction," the latter being
something which I believe ought to be a near-top priority right now.