AltME groups: search

Hmm... i think tally func cuold be speed up with the Tombon's trick 
(using UNIQUE)

Looks mostly the same in speed:
>> time [fast-tally1 copy Data] 50
== 0:00:00.379225
>> time [fast-tally2 copy Data] 50
== 0:00:00.392215

We tried, but that has definitely been declared an R3/Plus function, 
not native. Making ACCUMLATE? native wouldn't help much - the mezzanine 
version is really fast already. You won't be able to get functional 
language speed even from a native because that requires compiler 
support, and REBOL doesn't have a compiler at all.

speed is a priority especially with Rebol which can be really slow 
if you don't take care

I agree, using recursion for walking through hierarchical structures 
is a good approach as these structures usually have a depth limit 
far below the stack limit (e.g. parsing XML data) . In the last years, 
I've found that using block parsing for block! trees walking was 
probably the most efficient approach (code size and speed wise).

Wow, that make string! change to join/rejoin yields about a 300% 
speed increase! Definiately one to backport to R2.

R3 is still beta -- so may be full of debugging code.

Also, are you comparing my times with yours? We have may have different 
speed machines

Yeah, usually the focus lies on code size (who writes the tiniest 
solution) which isn't always the best solution to a problem. Well, 
there aren't "best solutions" anyhow because it always depends on 
what you need (speed/stability/security/readability/etc.), often 
enough you need to make a tradeoff there so you can't really say 
one is best. But your idea would be a good start to improve code 
golfing. Now you just need to make a nice website that I can visit 
;)

Speed or safety?  that is the question.

>> to-integer ""
== 0
>> to-decimal ""
** Script Error: Invalid argument:
** Where: to-decimal
** Near: to decimal! :value

I've had REBOL use up over 700MB of RAM without isues or dramatic 
speed drops... but having millions of items, make sure you pre-allocate 
your hash-table, cause if you keep-appending to the same table for 
each entry, it will get  exponentially slower.

Well it's interesting as a study dialect. But to be honest guys, 
i don't see the interest  to have them in Rebol.

Because we can do much of the use cases rebolek showed us  with one 
or two lines of rebol code.

And i don't need to say that it will got lightning speed by comparison

But anyway, It's lot of fun to do such things with Rebol.

Yeah, it is a common idiom. But some symmetry to REMOVE FIND FLAGS 
FLAG would be nice, and I don't expect Carl or anyone to be willing 
to replace REMOVE FIND by another native or mezzanine. That wouldn't 
be worth it.

For now, I've decided to go with 

	>> union package/changes [weight]
	>> exclude package/changes [address]

since speed is really nothing to worry about in my case now.

true, but bitsets have  lightning speed in comparison.

Found ...

f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
]

Obviously it was done to speed up the search

much less work for the GC and big speed gains on large series.

No way, I did not optimize for speed

because of liquid's lazyness, very few things are actually optimised 
(really need to)... but right now I have a problem on initialization 
where there is so much linkeage being done, it does create a nagging 
pause on startup.


I already know a few things that will greatly optimise liquid itself, 
and will implement speed minded plugs specifically for GLASS, but 
your input will be invaluable.


you've spent sooo much time on this specific aspect of REBOL coding 
that it will come naturally to you.

in the last 6 months, I've allready optimized liquid's kernel by 
a factor of at least 50 times I think I can speed it up at least 
10x more.  on specific points, I can probably improve it even more. 
 that will probably come at increased memory use for some plugs though.

>> a

== [23 43 55 28 345 99 320 48 22 23 95 884 1000000 999999 999998 
999997 999996 999995 999994 999993 999992 999991 999990 999989 999...
>>

(a is a block with 1, 000,012  integers) 


ind: func[series value x][


	st: now/time/precise
		
	while [x > 0][
		
		result: make series 0
		series: head series

  parse series[any [series: 1 1 value (append result index? series) 
  | skip]] 
		x: x - 1
	]
	et: now/time/precise
	fin: et - st
	print fin
	result 
]

feach: func[series value x][

	result: make series 0 
	st: now/time/precise
	
	while [x > 0][

  foreach[s p v] series [if s = value [append result reduce [s p v]]]
		x: x - 1
	]
	et: now/time/precise
	fin: et - st
	print fin
	result 
]

>> ind a 23 10
0:00:01.249
== [1 10 999990]
>>

>> feach a 23 10
0:00:01.01

== [23 43 55 23 95 884 23 43 55 23 95 884 23 43 55 23 95 884 23 43 
55 23 95 884 23 43 55 23 95 884 23 43 55 23 95 884 23 43 55 23 9...
>>

10 iterations each.. 


foreach is the winner speed wise.. as a bonus, If i use foreach, 
I don't need the index?

Convolve effect could actually help get Lanczos filter implemented 
at mezz level with decent speed.

Oh, I forgot that the server it's running on has a mono-core Atom 
as CPU! Speed should be ok starting from a mid-level CPU.

I haven't got experience with routine! calls, so I can't say. A way 
to get the data to the C code is to save it on disk as BMP from REBOL 
first. If you need really high speed, this might not do it for you 
though.

One char per gob: that is simple, but maybe you can increase rendering 
speed by creating one gob per section of text which has a consistent 
font-size and style etc.

it doesn't change the speed, since there are no newlines.

no, what kills the speed is when you do newlines, especially if the 
lines are long.

but that means using face effects (and hence going thru view and 
back) which will kill the speed pretty quickly  :-(

wrt console I/O killing gfx speed.... with my new high-performance 
chrono lib, here are the results for printing... compared to a single 
(average) call to sine. 

[print ""]
0:00:00.000792139

[prin "."]
0:00:00.000168666

[sine 45]
0:00:00.000001014

Nice work.. it would be even more interesting if Cyphre's JIT could 
be used to speed up some of your functions one day.

Yeah, looks good - do you have any guess how this would compare with 
Algodoo (speed-wise) once you're done? It does use OpenGL, but I 
guess you could too.

http://www.algodoo.com/

right now, I'm still flushing out the raw maths, but somehow, AGG 
always seems to squash any speed gains I get out of better interpreter 
speed.

yes vector! is usefull, simply for speed considerations.   not sure 
either, if they where added back in A101/102

And Ladislav posts an improvement leading to 3x speed increase.

post your code

 ... I suspect it was as simple as adding a fiew widget names into 
 behaviors/tabbable via request-ui

posts an improvement leading to 3x speed increase
 ... where?

steeve: don't forget, that the 1s difference in TRAIN speed does 
not actually matter, since it is just a dictionary preparation. What 
matters is the speed of the CORRECT function

how easy it would be to do real time spell checking

 ... with a cut-down version of Ladislav's code (mainly limiting edits 
 to one char distance) speed is no longer an issue. I'm looking at 
 using draw to red underline all spelling errors in a text face and 
 then only popping up the spellcheck box on right-clicking a misspelled 
 word.


Problem is synchronizing red underlines with scrolling. R3's rich 
text support would make this trivia [by comparison] to implement.

stange I would not have thought that 'ADD and + would have any speed 
differences.

After looking at all of the various UI for Rebol that's currently 
available, and although they are all great in their own right, I 
can't help but think there's something missing.  I've found the rebol 
mashups I've done using Javascript, HTML, CSS and Flash.. to be so 
much more flexible, and of a higher quality... perhaps not in things 
like speed etc., but when it comes to eye-candy, View, and all of 
it's GUI libs come in third at best.


If you're running windows.. take a look at RASH.. a simple blue button 
that floats on top of all your other windows.. click it, and a panel 
pops up.. 

It uses Flash as the UI.. and it's really quite easy to tie Rebol 
into Flash..  and you can do it with core. Why there isn't more Flash 
/ Rebol mashups is weird

re: dbl-click problem. I can't reproduce this one. I assume this 
occurs on Windows? What is the dbl-click speed set to? (Control Panel|Mouse 
Properties|Buttons) Is it a mouse or pen (i.e. TabletPC) that generates 
the dbl-click in question?

Yes, windows ... and a mouse.  Speed is set to just to the right 
of middle.

Hmm - I always strive to mave my UIs navigable by keyboard for speed 
and this necessitates use of  the rodent - any way to give tabbability 
here too?

the idea is to greatly speed up text entry at the keyboard

Still ergonomists have thought hard on how to speed up typing on 
restricted keyboards .. maybe there is something there that can be 
taken to a full keyboard

Build 202 uploaded ( https://rebgui.svn.codeplex.com/svn/)
- Fixed password
- Added icon to tour.r
- Resized tour.r to fit smaller screens

- Reworked layout and display functions to remove duplicate show 
and do-events calls
- Removed do-events from tour.r and RebDOC.r


The layout/display change (apart from correcting numerous rendering 
anomolies and improving layout speed) may have caused other unforseen 
side-effects. At the very least it changes RebGUI in the following 
manner; previously you would write:

	display "A" [...]
	print "A"
	do-events

and get "A"  printed to the console. Now you write:

	display "A" [...]
	print "A"


and only get "A" printed to the console once the display has been 
closed. This now lets you write code like:

	display "A" [ ;do some stuff to set result]
	process result and display "B" or "C" based on result

This change is still experimental so let me know what you think.


Also, who actually uses tool-tips??? I've been debating whether to 
fix them so they work properly, or just remove them entirely. Thoughts?

Wow, RebGUI really picked up speed again. I'm still not biting the 
bullet to backport my fork of RebGUI.

The slow-down is from the query side not the RebGUI/table side. Table 
uses an iterator function so whether the table has 10 rows or 1,000,000 
it should be the same speed ... fetching 10 rows or 1,000,000 across 
a network is another story.

Why RebGUI uses request-file non-native requestor?
	- GUI consistency
	- speed
	- functionality
	- native requestor is broken on OS X

Can editor's position/size be set?

 - I can make the default smaller, what's your notebook screen res?

 - I'll probably add a /size refinement as well (I can see how you 
 might need a small or large editor in certain situations)

btiffin, I would prioritize all the new stuff at first to get everyone 
up to speed.  I know that Carl use to supply us with a changes document 
to simply update us on the changes with a new release.  That might 
suffice better to get everyone up to speed faster.

Aside from that though, not much point. Even if you are talking about 
the Silverlight or Compact runtimes, it's still much larger than 
REBOL on its own engine. As for speed, who knows; a lot of smart 
people are working on the DLR.

A tiny bit of status report:


- Working on ports now. It's a very straight forward system, if you've 
been reading the docs.

- Carl found a bug in the garbage collector that would speed up a 
loop test case from 35.2 seconds to 6.4 seconds.

- After a while of core unicode testing, graphics is finally going 
back in. The third test version of View with unicode is going to 
be released soon.
- Still no unicode support inside View graphics, though.
- 445 bug reports so far.

- HTTP protocol recently done (IMHO a very nice and super-clean implementation 
of http1.1 by Gabriele).

- Test case system temporarily put on hold. Ports are more interesting. 
:-)

- WAIT now switches between efficiency and accuracy. It's accurate 
but CPU intensive when selecting a WAIT lower than 1 ms, because 
in those cases it uses it's own routine for waiting, but it can be 
done much more accurately than the OS timer. When above 1 second, 
it uses the OS timer.

I personally want to see LIST-VIEW capabilities in R3's list view 
what ever that will be, but it will probably be split up in simple/advanced 
for speed vs. bloat factor.

so my idea to speed the search process instead of having to use foreach 
loops would be to convert my list into an hash table like data structure 
using the postions as index

I said it xy years ago, that it will happen. Nowadays browser is 
considered being "universal app container" ... the strange thing 
is, that while it provides crap speed (even with AJAX) compared to 
native apps, ppl are forgivable here. But - in order for browser 
to keep its chances, we need to keep the standards. Looking at W3C 
and all its MLs, I wonder how cross platform, cross browser support 
goes. There are technologies for multimedia like SMIL, etc., SVG 
- crappy supported.

They would switch for the added benifits rebol pages would provide 
but they would still be able to accesshtml until those sites cought 
up to speed...

Reading this discussion since Terry's first post 8 hours ago (the 
"be serious" one), shows to me how hard it gets to think outside 
the box and that's another challenge when it comes to marketing the 
REBOL browser. When we think of browser, we automatically refer to 
a whole range of technologies and languages. It's something so ingrained, 
we never notice it. Partially you can say it's the same for a PC, 
as it's very likely to run Windows and that if you want to read an 
electronic document mailed to you from an average person, it's very 
likely to be written in MS Word. That's not how we want it to be. 
That's how people think. They think in axioms and familiarity, because 
they don't know any better.


I think the marketing should play strongly on familiarity, such as 
with the aforementioned GMail clone, where it's easy to tell the 
difference in speed between the two technologies. Keep duplicating 
existing stuff. I disagree that the average person can't tell the 
difference. I've observed average people praising that GMail now 
runs faster in FF3 than it did in FF2.


The REBOL browser is disruptive technology. It will be able to do 
things that normal webbrowsers won't be able to do for the next 5 
years at least, if ever. But only if it's done right, by playing 
on familiarity. If it's done right, dumping the traditional web can 
happen faster than we think and I would do it in a heartbeat.

I imagine that if Reichart was ever to do QTask for the REBOL browser, 
he could probably build it alone at 1/3 or 1/4 the time that it takes 
to build it for a traditional browser and the final product would 
run faster.

Brian, I disagree that my system was slow. Indeed, I don't think 
you can do it much faster unless you make it more low level (ie. 
users need to specify more). Even then, I still think the speed would 
be the same.

Gabriele, cool, I was just concerned about speed. I suppose calls 
to external APIs are likely to be less frequent than internal manipulations, 
and UCS encoding would make the internal code faster. Either way 
I'm sure that it will be handled :)

Steeve, my wifi antenna is not running very well right now, so there 
might be speed issues.

I think Queue timers might be good for us. Such low level changes 
might speed up View and make it more resource friendly. Not sure 
Carl wants to experiment, so maybe we will have to try once View 
is open-sourced.

Henrik: Cool stuff so far. But, aren't you the guy doing the list-view 
stuff?


I think the current VID should really be stressed on a complex real-world 
example: A Table/Spreadsheet that can handle 1 Mio. rows with high 
speed a la Excel. It's a widget type you can use to show stuff or 
even let people enter something.

There is the matter of getting into the VID 3.4 code which would 
take a few days, before changes could be made and those changes must 
be of very high quality. I'm not sure it's of much help right now 
to speed up the process, but in longer term it would help getting 
some details right.

just one question about R3:

to convert a 32 bits integer to a binary serie i currently use that 
trick:
>>my-int: 150
>>debase/base skip tail to-hex my-int -8 16

it's quite inelegant and memory consuming (especially the to-hex 
function)
we need a more speed and compact function in R3.
I know another one trick using struct! but it's slow too.

To convert binaries to integers we don"t have such problem, cause 
[to integer! my-binary] works well and is short.

Graham: Open or closed development. Right now, I'm not sure it would 
speed anything up. I think things would actually slow down. But this 
has been discussed to death.

Oldes: Is there something new with Rebcode?


Nothing new, but your requesting it means that you don't remember 
the problems the old rebcode had.

The bad news:

- Rebcode didn't work in R2, it was unstable and frequently crashed 
REBOL, very pre-allpha.

- Carl is unlikely to make a build with rebcode because of the above, 
and because he is focusing on R3.

- R2-style rebcode would be slower in R3 relative to the speed of 
regular R3, partly due to changes in function word lookup.

- Any rebcode dialect for R3 would be incompatible with R2 rebcode 
on a basic semantic level.

The good news:

- R3 has features that will make it relatively easy to add our own 
rebcode-like dialect.

- Even though the R2 semantics wouldn't be good, there are more tricks 
we can do to get more speed.

- The main reason that we don't get as much of a relative speedup 
for R2-style rebcode in R3 is that R3 is faster itself.

Nonetheless, I am doing whatever I can to speed up regular R3 whereever 
it is reasonable to do so. The profiler is my friend :)

If you want to make a grandma language, good for you. I say language 
instead of dialect because changing the syntax changes the langage 
- dialects use thee same data syntax, that is where they get their 
speed.

Do you not see the simplicity of foreign! data?   No speed problems, 
the lexical gets to a point where it would throw and it stashes a 
foreign!, keeps on truckin'.

I love the speed of typing numbers. I don't want that to go away.

The only way to truly speed up development would be to clone Carl.

Sunanda try profiling the R3 version with and without the xxx word 
and see if there is a speed difference. If not, then the word appears 
due to binding on first use of the block.

I actually would only request it for the speed.  I already have the 
produced the functionality but it obviously isn't native so I figured 
we could gain some speed.

Tasks are very interesting, as it will render slow and large cooperative 
threading libraries for R2 moot. You create a task like you create 
a function and it can be used in the same way, except you are returned 
to the console right after calling it. Also networking is completely 
async on the lower level, which helps speed up network operations. 
You can achieve similar things in R2 through hacks, but it's not 
well documented or stable.

I think I know what is wrong: Carl is thinking near the speed of 
light, thus time slows down for him, so while it takes two months 
to get the next R3 release to the public, it only takes a day for 
him. :-)

Pekr, I want to do a code audit, but I'm thinking now whether I should 
do that in the open to speed things up a little. I'm not sure.

However we are in the middle of a big change. Once the new messaging 
system and the GUI will be complete the whole speed of REBOL3 will 
shift up again.

Looks like parse could help with the speed, but it might be harder 
to get it right.

something related, in the past i made some tests to simulate hashs 
with integer keys in R2. I used a bitset as an index, mixed with 
block of blocks to store data.

my tests show that for 10000 records,  finding data is near as fast 
as with hashs. 
actually it's incomplete but you have the idea with this:

REBOL []
f: fast-dic: context [
	size: 100000

 hash: 128 - 1	;** hash size speed up the search, must be a power 
 of 2 - 1 (ie. 15, 31, 63, 127, 257 ...)
	master: copy/deep head insert/dup/only [] [] hash + 1
	index: make bitset! size
	flag: func [idx [integer!]][
		unless find index idx [
			insert index idx

   insert/only insert tail pick master idx and hash + 1 idx copy []
		]
	]
	flag?: func [idx [integer!]][find index idx]
	deflag: func [idx [integer!]][
		remove/part index idx
		remove/part find pick master idx and hash + 1 idx 2
	]
] 

t: now/time/precise
loop 10000 bind [flag random 99999] f
print now/time/precise - t
t: now/time/precise
loop 10000 bind [flag? random 99999] f
print now/time/precise - t

The real advantage of list! wasn't the speed though, it was the alias 
persistancy. That was the source of the bugs in list! too.

At least I think Carl was somewhere talking about that. And that 
it could for example speed the boot time, which could be useful for 
cgi aps.

Although Carl was actually talking about rebin to speed up the boot 
times, not RIF :)

The only thing I could dispute would be the "huge" part. References 
wouldn't necessarily need to be stored as full 64-bit integers if 
there is an index, so there could be even more space savings, though 
speed would be king for RIF I expect. In any case I expect much more 
space savings than REBOL text syntax.

Yes. Reason: To simplify and speed up MAKE, and REBOL, and to make 
code generation easier.

It seems like speed is more important than memory in this function.

That will require switching to PARSE for speed.

Would you need a /reverse option? ACCUMULATE is already almost as 
fast as we can make it in REBOL, and more options would slow it down. 
The only way we could speed it up more now is to fix an APPLY bug 
with op! functions.

Anyway I hope R3G has robust keyboard handling .. for speed a mouse 
driven gui sucks

Henrik, do you need help?  Maybe I can get involved - if interested 
- just get me up to speed on it.

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Dunno, but I would like to have transitions and wipes available. 
It could be done even nowaday, just look at Jeff Kreiss present.r 
script. IIRC it is available on rebol.org. It contains whole dialect 
for movement, fading, etc. What I worry about is - low speed of REBOL 
for such stuff, at least in REBOL level and without Rebcode, we can 
better forget it. We also need to implement different type of timers 
etc. But generally - dunnof if we can get smooth results without 
real HW acceleration ....

I was against new system, but I am satisfied with Carl's explanation 
of his POV. He needed streamlined channels for chat, bugs, CVS, filesharing. 
New system, in comparison to AltME, gives us:

- threaded discussions
- ranking
- tagging
- threaded discussions
- message/topic moving
- versioning system
- document management. Docs posted anywhere to any message.
- console version


So far, the big minus is - no GUI client. But - that might be over 
in few months ... So - if we think of RebDev as nothing more than 
RT's supporting infrastructure, I am OK with it. It is just that 
for fast dev related chat, e.g. nowadays GUI related, it can't reach 
Altme comfort and speed in not more than 20%. Threading is very confusing 
now ...

ill dig out my radial menu thingy and update it for r3 and test it 
for speed.. have a old version at http://rebol.mustard.co.nz/readial.tar.gz

Accessors allow you to provide your own functions to how the code 
interacts with (accesses) the object internals.  typically you have 
get/set/print/convertion accessors.

the range and flexibility of accessors is largely dependent on the 
language and the speed considerations of implementing "public" accessors. 
 


most modern oop languages  implement accessors.  some languages, 
like python, let you change all the accessors which the language 
itself has access to.

one of the things accessors allows is to create or simulate custom 
datatypes (depending on how complete the accessor interface is).

so as an example, we could do this:

float-pair: object [
	x: 0.0
	y: 0.0
	set: func [value [string! pair! decimal!][
		switch 
	]
]

---> thus, does become a speed issue.

No, I really don't think. I stated it clearly - I have enough experience 
with management to understand current situation and I can tell you 
- having full sources available nowadays would make NO difference 
to speed or quality of R3 development. When product is stable, I 
can imagine how sources do really help ppl to track potential problems, 
provide fixes. But many parts of R3 are simply missing, not yet done. 
Now how many of us here are able to produce the C code quality Carl 
would accept into REBOL anyway? Sooner or later we are going to get 
plug-in interfaces - then we can experiment with some C code extensions 
...

I've been using hash! for a bit, but there are too few advantages 
for it to be directly useful. The main advantage is supposed to be 
speed, but usually when you need to do real work with a hash! you 
need to convert it to a block!, which slows the whole script down 
more than if you just used block! correctly from the beginning.

I think it could be faster if you bypass the fon't engine. At least 
I suppose that font engines are using bitmap caches to speed up the 
rendering anyway. But of course it should be used to render in the 
size for which the font is created.

Interesting...


I'm using blocks to manage a lot of name/value pairings which I will 
sort and copy/part the top x items.  I was hoping to be able to utilize 
the speed of map! for doing this.  Maybe I should use map! while 
creating/modifying and then when it comes time to pull top x items 
I could convert it to a block...

Ladislav, strangely enough there are also persistent words defined 
for the words in the spec, if they are set with set-words in the 
body. You can access them through self. It's just that the spec takes 
binding priority, so direct access to the words in the spec will 
be bound to the spec. There are many potential advantages to this, 
but the main reason this was done was speed.

While we're talking about memory management, will it be possible 
to add in R3, a mean to adjust or tune GC behaviour by exposing some 
of the internal parameters? The goal is being able to adapt the tradeoff 
between speed and memory usage in various situations. For example 
: being able to set a max amount of memory for a REBOL session.

If Rebin store slot values, it will not be compact, same memory overhead.

To binary! furnish a more compact way to store data, with a speed 
issue indeed