What was the replacement for this deprecated one here:
Given the Xojo’s documentation says:
Note the difference between
Dim p As Ptr = mb
Dim p As Ptr = mb.Ptr(n)
So the replacement would be something that replaces “Dim p As Ptr = mb”
Do a REALLoadObjectMethod on “Operator_Convert() As Ptr”.
I can confirm this works even in 2006r4
I would still like to have those SDK Functions being undeprecated.
Using Operator_Convert is in my case about 10000 times slower compared to REALMemoryBlockGetPtr.
REALGetPropValueInteger is about 200 times slower than REALMemoryBlockGetSize.
Why is Operator_Convert slow ? Are you loading it every single time the function pointer ? Or is just calling it slow ?
The PropValue / Getter setters are very slow for sure. Ideally one would have wanted to be able to load the function pointer to those that have getter and setter. I am not sure how one would represent that since there it can be quite random which property has getter and setter and which not.
I can understand though that having every single thing in the SDK is going to make the applications huge. Since Xojo needs to have entry points for them internally also.
Well, if I have a memoryblock function which does a little thing, the overhead for getting the pointer is significant and can slow things down.
Simply make a test yourself and call it 100000 times and see how long it takes.
REALMemoryBlockGetPtr simply returns pointer to data which probably is just a property at an offset of the memoryblock.
Loading Operator_Convert function takes a long time for computer. And I fear we can’t simply cache it due to overloading in memoryblock subclasses.
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.
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.
- read ptr from memory directly.
- call REALMemoryBlockGetPtr
- call once REALLoadObjectMethod for Operator_Convert and cache it
- don’t cache function pointer and query them each time.
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.
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