I'd like to go for reusable structures if possible. The accessor would
simply recall or set a single piece of data to a hard coded location in
the memory block; and this is no different than what would be done
without the accessor. Are you absolutely possitive there would be a
performance hit?
Accessing data in a memoryblock using, say "doublevalue" involves a
function call (or possibly several internally) to access the data. If
you were to subclass that memoryblock and create a new function
"XasDouble" then you would have to call the function XasDouble which
would then call the function "doublevalue", and so you have added a
function call, which will degrade performance.
If on the other hand you were to still access the data in your subclass
using doublevalue directly, then there would be no performance hit. You
could also make accessor functions that operated on several values at
once (e.g. a scale function that scaled x y and z by a given amount) in
which case the function call overhead would be reduced (in the scaling
example you would now have an effective overhead of only 1/3 of a
function call per access).
It's also worth bearing in mind that for many purposes the overhead of
a function call is negligible, and may be far outweighed by the
convenience of having meaningfully named functions. You could always
convert such calls back to doublevalue, etc when optimising the final
program.
Let me give a more specific case. If I were to load information into a
3DS type data structure I would probably want to store stuff like faces
and verticies (where verticies are 3 values for a points in 3D space
and faces are 3 values referencing vertices; just like a trimesh in
Quesa) in subclasses which would then be stored into a "Face" or
"Vertex" array. If these subclasses were memoryblocks then the
verticies would be very convienient to send straight to OpenGL. All in
all this would be much cleaner than storing all face or vertex values
into a large multi dimentional array.
Indeed, that is certainly the way to go imho.
Anyway are you CERTAIN that using these subclasses with accessors would
be slower than accessing the memoryblock directly?
Definitely, but not much.
At the end of the day you presumably chose to use REALbasic over C
because it's more workflow oriented - i.e. it promotes ease of use and
rapid development over performance. It is not worthwhile in my opinion
devoting a great deal of effort to eking out performance by obfuscating
your code. Instead write the simplest interface you can, ignoring
performance (within reason, don't implement each vertex as an object
for example) then if *and only if* the performance is too poor for
practical use, look into refactoring the implementation to optimise
performance.
If you want it fast, you can always rewrite it as a C plugin later when
you've got the interface worked out, in which case you will be able to
write code that is optimised far in excess of anything you could manage
using realbasic anyway, since C lets you access memory directly.
Nick
_______________________________________________
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>
|