World: r3wp

it is /binary by default.

i know

in fact it's depending of the type of the buffer

yeah that is true - which is very cool about REBOL.

i noticed too, that your buffer must be size of the requested size 
+ 1 byte, if not you get some errors

I copy data from a port using /seek and simply do-    to-block port-data 
and need no other conversion.

That is probably why it stopped at 15.

I think index was at 1

the index is zero based, don't forget

Nope - still reads just 15

Requested size + 1 or more bytes.

yeah I was checking empty buffer

did you try the profiler script ?

No, I'm in the middle of something else

I'll open another console  real quick

64   0:00    351909:41:29.709551615      0
128      0:00    351909:41:29.709551615      0
256      0:00:00.016     351909:41:29.709551615      0
1024     0:00    351909:41:29.709551615      0
2048     0:00    351909:41:29.709551615      0
4096     0:00    351909:41:29.709551615      0
8192     0:00    351909:41:29.709551615      0
10240    0:00    351909:41:29.709551615      0
16384    0:00    351909:41:29.709551615      0
32768    0:00    351909:41:29.709551615      0
65536    0:00    351909:41:29.709551615      0
131072   0:00    351909:41:29.709551615      0

pretty consistent

something is wrong

You need to print out the time to more precision.

you need to use a big file as data

Yeah I just pasted it

hold on

64   0:00:10.639     0:00:00.000020633   515625
128      0:00:05.444     0:00:00.000021116   257813
256      0:00:02.761     0:00:00.000021418   128907
1024     0:00:00.733     0:00:00.000022744   32227
2048     0:00:00.374     0:00:00.000023209   16114
4096     0:00:00.218     0:00:00.000027057   8057
8192     0:00:00.124     0:00:00.000030776   4029
10240    0:00:00.109     0:00:00.000033819   3223
16384    0:00:00.078     0:00:00.000038709   2015
32768    0:00:00.078     0:00:00.00007738    1008
65536    0:00:00.047     0:00:00.000093253   504
131072   0:00:00.063     0:00:00.00025   252
>>

Looks like 64k is a good value for you.

yeah it seems

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