On Sep 14, 2006, at 9:45 AM, Daniel Stenning wrote:
With regard to performance, I am interested in knowing how far the RB
compiler goes towards optimising arrays for speed.
For example:
1) If I have a dimensioned array :
dim myFixedArray(123) as UInt32
and NEVER anywhere in my project do I use "dynamic" commands on
it,such as
Append, Remove, Redim etc ..
Does RB recognise this - and store and treat the array internally as a
contiguous block of UInts in the same manner as C ? Or is each
element
handled by a reference or some indirect addressing scheme ?,
thereby adding
an extra layer of code execution?
If I then use array indexing to access any element
eg:
for I as integer = 0 to 123
myIntVar = myArray(i)
Next
Does this internally simply use C style index offset addressing to
access
the elements ( plus bounds checking of course if enabled ) or are
there
extra stages necessary?
2) If the answer to 1) is yes - ie fixed size arrays are always
contiguous
C style blocks , how are dynamic arrays treated ?
3) If I declare a fixed size array of RB structures, is this
implemented
internally in a similar fashion ( C style contigous blocks ) to 1 ) ?
4) If the answer to 1 is yes - how about adding some ability to map
memoryblocks that represent a C array if fixed size data such as
integers,doubles or structs on to ab RB array. I say this -
because when
one is processing data blocks obtained through a Declare call, it
would be
very useful to be able to maintain speed and all the language to
process -
for example large blocks of integers or floats ( say Audio frame
buffers )
without incurring the penalty of doing a copy and translation to an RB
array.
Naturally one could just use the MemoryBlock built in methods to
address the
block directly, but this currently requires the developer to calculate
offsets himself.
Another option would be for MemoryBlocks to access data by [index]
( like C
) instead of by byte offset. For integer, floats, and structures
this
should be doable.
The only objection to this in my mind would be "religious" ones
that have
more to do with keeping RB "basic" for "basic's sake" and "Nanny-
like",
rather than anything to do with assisting programmers write good
and fast
code.
So-called "religious" objections aren't necessarily unreasonable.
I'd rather not see the language become overly cluttered with an ever-
increasing list of special constructions and syntax.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
