Re: starting streams at offsets

"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message news:MPG.216561b5a6a144d64cd@xxxxxxxxxxxxxxxxxxxxxxx
Doug Semler <dougsemler@xxxxxxxxx> wrote:
> You're not alone - I see calls to Seek() far more often than calls to
> Position. The Position property is one of those "discovery" things -
> once you've seen it, you tend to use it, but a lot of people haven't
> seen it :)

Not sure if it's applicable to this group but I was curious about it. Is
there any performance hit by using the "Position" property versus
"Seek(offset, SeekOffset.Current)?

I don't know - I would expect there to be any though.

Reason I ask: Example, the FileStream class Position property resets the
seek from the beginning of the file regardless of the current
position...just wondering if the reset back to the beginning of the file
hurts performance any versus a seek from the current offset...

It doesn't reset back to the beginning of the file - it resets
*relative* to the beginning of the file, i.e. an "absolute" position.
Assuming the OS maintains some sort of integer to say where the stream
currently is, it could easily optimise an absolute call to a relative
one if that gives a performance improvement in a particular filesystem.

I guess if you were doing a lot of this it and had performance issues
would be worth benchmarking, but I wouldn't expect to see a lot of
difference.



That's what I wasn't sure about. Some (older) OSs that I had worked with in the past (notably earlier versions of HP-UX and I think SunOS 4 IIRC) would basically invalidate the I/O cache for the file if you did a seek from begin over current because it made different assumptions based on Begin, Current, End...whereas a forward look/backward look off a current offset may or may not have have invalidated the cache (depending on the size of the seek, etc). But that may have been more of a hardware architecture layout than anything else)

in other words, if your current fp was located at say offset 32,127,181

seek(32,100,101, BEGIN) would often cause a cache flush whereas seek(-27,180, CURRENT) more often than not did not...

(but, like I said, Windows wasn't the OS I grew up on, and I/O is not the bottlenecks in image processing which is my current balliwick. :)

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

.

Relevant Pages