[REBOL] Re: callbacks
From: lmecir:mbox:vol:cz at: 6-Nov-2007 11:16
Hi Max,
> hi all,
>
> I'm sorry to say I submitted something odd as the memcopy function.
>
> its actually only 0.5% slower than ladislav's but has two differences,
> *its returns a binary type
> *it should be 100% GC safe
>
regarding the speed: according to my measurements:
include %peekpoke.r
include %timblk.r
a-binary: #{000102030405060708090a0b}
max-memcopy: func [
{copies a region of ram given at address with sizeof length.}
address [integer!]
length [integer!]
/local struct-struct buffer addr
] [
address: make struct! [address [integer!]] reduce [address]
struct-struct: make struct! compose/deep [ struct [struct! [ (head
insert/dup copy [] [c [char]] length)]]] none
addr: copy third struct-struct
change third struct-struct third address
buffer: copy third struct-struct/struct address
change third struct-struct third addr
buffer
]
lad-memcopy: func [
{copies a region of ram given at address with sizeof length.}
address [integer!]
length [integer!]
/local struct
] [
address: make struct! [address [integer!]] reduce [address]
struct: make struct! compose/deep [s [char-array (length)]] none
change third struct third address
struct/s
]
t-max: time-block [max-memcopy address 12] 0,05
t-lad: time-block [lad-memcopy address 12] 0,05
t-max / t-lad - 1 * 100 ; == 187
, so the speed difference is 187% not 0.5% (here).
Regarding your second premise supposing your Memcopy is GC safe.
Actually, due to the fact that it "consumes" more memory than my Memcopy
version, it is more likely to crash the interpreter when accessing a "GC
unprotected" memory. As I said, the source of the problem is the fact,
that you most probably allocate a chunk of memory using Rebol and give
it to a C routine not protecting the memory against GC. That is most
likely the true reason of the crash instead of the poor Memcopy
function, which just happens to be the victim obtaining a GC-candidate
memory.
-L
