I know loading them is awful, time wise.
But I would store the pointer.
I dont understand why you cannot cache. Since REALMemoryBlockGetPtr does nothing for overloading anyhow so it would be same thing I would think if you store cached function pointer and REALMemoryBlockGetPtr, neither of them will support overloading
Well, maybe Joe can comment on whether caching this function pointer is okay?
or if Xojo framework every subclasses/overwrite it.
As long as the one you load originally when caching does not have overloaded operator then your safe. And the cached function pointer will work for all classes that inherit from it thus give you same result as REALMemoryBlockGetPtr.
But if the first one you cached was overloaded then you could be getting something else of course. Its not likely operator to be overloaded I would say though.
Well, I could just make a new memoryblock for that and query it for the function.
Hi Christian,
problem with speed really exists? or still exists?
10 000 times slower - sounds scary ))
Well, REALMemoryBlockGetPtr and REALMemoryBlockGetSize work. They grab the function pointer on first run and than just call through. That is fast.
Calling REALLoadObjectMethod for Operator_Convert has an overhead which is magnitudes faster.
faster? above you told slower.
please read faster as slower…
getting Operator_Convert function pointer takes time.
As It could be overwritten you may need to call it always.
So speedwise:
Currently I do 2.
If you mean poking inside the REALobject itself, don’t. The internals are subject to change and it will only hurt users.
I would recommend against this too, though more of an academic point to warn about doing this in other situations. It’s possible, albeit very unlikely, that you could get given a subclass of MemoryBlock that overrides this method.
Hi Joe,
can you give more light on reasons why and what?
Also agree that MemoryBlock - means ability send/get binary data between Xojo APP and plugin.
We need maximal speed and minimum code.
The above code-examples looks “scary”, a lots of line code, workarounds about exceptions…
May be your team can consider this as important feature for Xojo SDK?
I mean direct API to MemoryBlock?
We going to continue to use deprecated methods in hope you will not hurry you kill them ))
The best for us would be to remove the deprecation and than change size function to RBInteger.
Or a way to know if it is a normal memoryblock vs. a subclassed one?
If there are subclassed ones?
aha, I see, old funcs depend on RBInteger, which is 32 byte size…
We do not use any sub-classed memory-block
btw, I was going to ask.
In the past REALstring was positioned as thing, which is able to keep and pass binary data (with \0).
It seems on that time MemoryBlock was not inside of REAL SDK.
in SDK 2015, I have notice steps to make REALstring more close to encoding.
Should we stop to think about REALstring as binary-data-container?
REALstring is still good for binary data if no encoding is set.
MemoryBlocks are better often.
Depends on what you do.
If you need to pass binary data to app to write to BinaryStream, Database or Socket, you better keep using strings.
no, it’s int and that makes it 32bit. Better would be RBInteger which is 32 or 64bit.
Is there a bug report for this?
I am guessing the reason why it is so much slower (even if you have the function pointer pre-loaded) that we are getting pointer to their actual plugin wrapper and not to the function.
I was bitten by this badly where I was loading my own plugin function and could not understand what on earth was not thread safe in my code. Reason turned out to be that REALLoadObjectMethod did not give me pointer to my own function but to the Xojo wrapper they create around Plugin code. And that wrapper does all the Yields and checks and things that make it not thread safe from point of view of Xojo’s awful thread model.
So from this I am guessing maybe same thing applies when we do dynamic load on Operator_Convert, making it so much slower with all those checks, and probably automatic yield (making it not thread safe) and so on.
Xojo really should have plugin wrapper functions automatically generated have all this turned off by pragmas. A plugin can decide after all on its own if it wants to Yield or not!