World: r3wp

in the past i found something...

It's native code.

perhaps it's the scheme to be exact

You might be thinking of one of these:
>> first system/schemes

== [self default Finger Whois Daytime SMTP ESMTP POP IMAP HTTP FTP 
NNTP HTTPS]

So what you really mean Steeve is that read-io is faster than copy 
correct?

That would make sense since read-io is lower level

i think it is

I never check to see how significant the difference was though.  
I might try  a test on a million records or so

I have got to backport the R3 profiling functions to R2 :(

Would be nice Brian but I got good ole stats/evals

speaking of backporting is 2.7.6 the end or is 2.7.7 still a possibility?

Further R2 releases will wait until after the R3 developer release, 
but they are coming.

The R3 profiling functions are wrappers around the R3 stats, so I 
just have to translate that to the R2 stats.

i think that in the past i saw the  source of the file-handler even 
if i can't find it anymore in my sources.

i have the sources of the handlers of other shemes in some proto 
scripts delivred with the commercial version of view.
But nothing else... i loose my memory...

read-io shouldn't be used with /seek it appears.

in fact they should make it so that  it CAN'T be.

need it to throw an error  or something.

why ? i use it with /seek as well

how many characters do you attempt to read each time?

seems with see you only get 15 characters to fill the buffer

see = seek

pass it a greater number and it will still only return 15

works ok with direct though

I think I ran into this problem before

Gonna check Rambo.

Ahhhh, I see.  I just discovered something.

Looks like an empty string is about 16 bytes

Better becareful to size your buffer when using read-io.

It doesn't expand beyond a default of 15 characters unless you define 
it as such.

So in other words if you set your bufrer as just:

buffer: "" then you going to only get 15 chars back.

So instead you need to define it as large as needed:

Well, at least it doesn't overflow :)

buffer: make string! 1024

Yeah true Brian, and maybe that is why.

i give you a script i used to profile the ideal size of the buffer 
used with read-io to have the best perfs.
On my computer the best size for the buffer is 8ko or 16ko.

REBOL []
f: open/seek/binary %large.dta

foreach len [64 128 256 1024 2048 4096 8192 10240 16384 32768 65536 
131072] [

	f/state/index: 0		;*** Problème quand on emploie read-io :
					;*** apparement c'est un bug, par défaut l'index est à 1
					;*** du coup, le premier octet n'est jamais lu
	

 buff: make binary! len + 1	;*** Encore un bizarerie, si le buffer 
 a exactement
					;*** la taille voulue, read-io lit un octet de moins
	n: 0
	recycle
	t: now/time/precise

 while [0 < read-io f buff len] [n: n + 1 clear buff f/state/index: 
 f/state/index + len]
	print [len tab v: now/time/precise - t tab v / n tab n]
]

close f
halt

See your declaring the size of your buffer so wouldn't have seen 
the other problem.

you don't need the /binary switch with seek in 2.7.6

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