World: r3wp

Paul, it's just using port/state/index is theoricaly faster than 
at (because at is a wrapper)

internally 'at uses port/state/index

you can  see the source (i don't remember where)

iirc

the most annoying overhead comes from the wrapper of the copy func.
you should use read-io instead of, if you want very fast access

read-io and write-io use correctly the port/state/index, just don't 
forget that port/state/index is zero based (seems to be a bug)

Steeve, yeah I would assume that is the case.  So the difference 
your seeing in performance is really just a small one as a result 
of the 'at then being a wrapper?

I'm might do some tests here to see myself

agreed it's a small overhead concerning at, but not concerning copy 
(see the source if you find it)

source for what?

source for the file port handler, ok i'm looking for it....

You can't see the source of the file port handler.

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