On 7/26/16 12:58 PM, Charles Hixson via Digitalmars-d-learn wrote:

Ranges aren't free, are they? If so then I should probably use stdfile,
because that is probably less likely to change than core.stdc.stdio.

Do you mean slices?

When I see "f.rawRead(&item[0 .. 1])" it looks to me as if unneeded code
is being generated explictly to be thrown away.  (I don't like using
pointer/length either, but it's actually easier to understand than this
kind of thing, and this LOOKS like it's generating extra code.)

This is probably a misunderstanding on your part.

&item is accessing the item as a pointer. Since the compiler already has it as a reference, this is a noop -- just an expression to change the type.

[0 .. 1] is constructing a slice out of a pointer. It's done all inline by the compiler (there is no special _d_constructSlice function), so that is very very quick. There is no bounds checking, because pointers do not have bounds checks.

So there is pretty much zero overhead for this. Just push the pointer and length onto the stack (or registers, not sure of ABI), and call rawRead.

That said, perhaps I should use stdio anyway.  When doing I/O it's the
disk speed that's the really slow part, and that so dominates things
that worrying about trivialities is foolish.  And since it's going to be
wrapped anyway, the ugly will be confined to a very small routine.

Having written a very templated io library (https://github.com/schveiguy/iopipe), I can tell you that in my experience, the slowdown comes from 2 things: 1) spending time calling the kernel, and 2) not being able to inline.

This of course assumes that proper buffering is done. Buffering should mitigate most of the slowdown from the disk. It is expensive, but you amortize the expense by buffering.

C's i/o is pretty much as good as it gets for an opaque non-inlinable system, as long as your requirements are simple enough. The std.stdio code should basically inline into the calls you should be making, and it handles a bunch of stuff that optimizes the calls (such as locking the file handle for one complex operation).

-Steve

Reply via email to