World: r3wp

Paul, there are other ways to reduce memory overhead that will get 
you more benefit, like using INSERT/part.

in what way?

can't read with insert/part

Not here. I was just using an example.

ok

I can't think of a better options than copy/part at this point

Without read queueing, neither can I.

what about pick?

be nice  to have pick/part

without the  overhead of copy

pick already works on /seek ports

Do you need to open/direct with read-io?

no

but the head moves as you read with /direct

must like forall does

It is not COPY that is buffering internally, it is OPEN without /direct.

I might do a test to see how fast 4 successive picks would be

and 16 picks

/seek is not buffered

it is like /direct

difference is that the index stays at head as you reference it.

How often do you need to do these reads, and can they be sorted in 
batches?

They do get sorted but they are done often and the batch sort is 
random sized depending on the request

You are using variable-length records rather than fixed length?

yes ;-)

Your wondering how right?

That is a lot slower. I am not wondering how, I've followed the discussions 
in your group.

slower than what?

Fixed length. Databases usually work in increments of disk pages 
because it is faster.

But at a cost

What if declared a field varchar[2000] and you only populate it with 
50?

Varchars are slower in practice. You can minimize the overhead of 
disk page access by packing pages if you have to. The OS reads in 
pages anyways.

I have minimized it to a greater extent.

A read of less than 1 disk page is just as slow as a read of 1 disk 
page.

I'm hitting you privately.

Ouch :)

say Oooooo to relax your sphincter muscles Brian

forget that

A 'bind question: how do I construct an object containing blocks 
without changing the blocks' contexts?  This bad:

>> id: #foo
== #foo
>> blk: [id]
== [id]
>> reduce blk
== [#foo]
>> ctx: context append/only [id: #bar bk:] blk
>> reduce ctx/bk
== [#bar]

This good:

>> id: #foo
== #foo
>> blk: [id]
== [id]
>> reduce blk
== [#foo]
>> ctx: magic-context append/only [id: #bar bk:] blk
>> reduce ctx/bk
== [#foo]

How to 'magic-context ?

Ugly answer:

magic-context: func [blk [block!] /local out][
	out: context join extract blk 2 [none]
	set out
 extract/index blk 2 2
]

I was hoping 'construct would do it, but alas not.

>> ctx: context append/only [id: #bar blk:] reduce blk
>> ctx/blk
== [#foo]

What is the best way to set all locals in a function to none before 
returning the result of the function if you have an extensive list 
of locals?

Myself I think that should be the default behavior.

I know for recursive operations that may not be desireable but I 
think they could introduce maybe another feature that allows certain 
ones to not be cleared.  For example, add an exclude native to the 
system to exclude the clearing of certain locals.

Is there a better way than just doing:

var1: var2: var3: ... varN: none

Well if you got say 15 or more it just looks ugly.

would be nice if you could  just have a command  inside your function 
that says  clear-locals.

That would require to get access to locals from the outside of a 
function. I'm not away of a way to do that.

I don't think so if it could be bound inside the calling function.