World: r3wp

but in fact, you should execute it several times, results can be 
different

Particularly on Windows.

in fact you can see that 16ko buffer would be a better choice (regarding 
to the first column)

(the third column)

you must do more tests

brb, i have to request some cigarettes and food

Steeve, I'm finding that copy/part using 'at on /seek is working 
at more speed for me.

you must have a special computer, it's not quiet logical and i have 
opposite results on my computer

s: now/precise
a: open/direct/binary %blah
idx: 0
a/state/index: 0
buff: make binary! 16

loop 100000 [read-io a buff 16 a/state/index: a/state/index + 16 
clear buff]
close a
t: now/precise
difference t s

my datafile is %blah

oh really ? ;-)

== 0:00:01.934

That is what I get with read-io.

s: now/precise
a: open/seek %blah
idx: 0
loop 100000 [copy/part at a (idx: idx + 16) 16]
close a
t: now/precise
difference t s

what I get with copy/part:

== 0:00:01.747

using a buffer of 16 bytes is YOUR problem, didn't you understand 
the result of the pofiling script

use a 16ko buffer instead (16ko = 16 * 1024)

Yes, I did Steeve, but that is my point - I'm saying for MY purposes 
read-io i s not faster.

Do you mean you MUST use only 16 bytes?

but copy use a larger buffer that 16 bytes, you don't compare same 
things

I'm comparing the same for what I need.

I only need to copy 16 bytes

Yes Oldes

no you are wrong Paul, copy is using an internal buffer of the port 
which are of several Kbytes

Steeve, your missing what I'm saying.

I ONLY WANT to read 16bytes.  I don't want any more than that.

not really

heh,ok Steeve, what do I really want?

i think it's you who don't understand, but anyway do as you want

ok steeve.

Paul, the data you are retrieving is in 16 byte increments and not 
contiguous?

Correct Brian.

Accessed randomly, not in order?

Yes.

I'll use read-io for my contigious stuff but not for this portion

each time you do a copy/part a new internal buffer is created, it's 
better to use always the same buffer. easy to understand.

more of that, the profiling script say that it''s faster to read 
16ko than 2 times  16 bytes

In that case, read-io would not work well for you directly without 
implementing your own buffering. Barring that, the buffering built 
into REBOL and used by COPY would probably be good enough. If yo 
want better performance you might to make your own buffers.

Steeve, why should I read 16k  when I only want 16 bytes?  I would 
then have to copy/part on the  portion of the buffer that I want 
if that was the case to get only the first 16 bytes of the 16k.

Correct Brian.

You would have some memory overhead if you go the COPY route because 
of what Steeve said, but that may be dwarfed by the disk overhead 
savings.

correct.

its the speed of the read which will be the most  impact.

because each time you do a copy/part you create new buffers in memory 
which are not erased by the recycler so that you should consider

using always the same buffer especially if you do thousands and thousands 
access in one second

I would still have to use copy/part on the buffer if I went with 
Steeves idea.

You would get better performance improvements by figuring out how 
to queue your reads so you get better disk locality, which would 
lead to better internal buffer usage.

But you don't get it Steeve, I would still be using copy/part on 
the buffer filled by your read-io to get just the 16 bytes I want.

memory overhead is the point

performance is the point.

Not in this case, Steeve.