FR: Allow MemoryBlock "freezing" for use by framework methods that just need data

Feature request:
feedback://showreport?report_id=55820

Sign on if you think it is a good one.

Be it text, binary data or a mix of both who’s total size you can not initially know beforehand, and has to be entered sequentially (you don’t have it all at once) writing to a memory block using a BinaryStrean is the fastest most resource efficient way to do it in Xojo…

But all the framework API’s only take strings and passing a memory block to them results in the bytes in the MemoryBlock being COPIED to the string wasting both CPU and RAM… One example is when sending or receiving data through a socket that was was assembled in a MemoryBlock and could be read from a MemoryBlock on the receiving end

I realize this is done so teh framework can count on teh data passed not to be modified… But strings being immutable and not being able to use mutable MemoryBlock in the framework methods is one reason Xojo code is seen as slow at doing somethings and forces resorting to plugins

But there can be a way around this that would allow us to write faster code when needed…

Create a “freeze” method on a the MemoryBlock class that once called makes that instance immutable without moving or copying the data under teh hood…

While the underlying bytes would not be as contiguous and so access not quite as efficient as with Xojo.Core.MemoryBox, none the less overall it would be much faster and use less memory than having to keep concatenating strings (even using join) or copying large memory blocks to strings… It would be a compromise with a huge win for writing certain types of code, and not break any existing code.

Once “frozen”, trying to write direct to it or through a BinaryStrean should throw an exception. It would be an advanced features that newbies would not likely trip over.

This would allow us to have a mutable MemoryBlock which can become immutable and then allow:

“Being able to pass around immutable chunks of data allows the framework to directly reference internal data and avoid having to copy it on the off chance it might get modified.”

as its says in the language reference for the Xojo framework immutable one.

this is exactly why the new framework has an immutable one

making the existing one support freezing would be a decent chunk of work since you’d have pt make sure that every other way to access & write to the memoryblock respected the “frozen” flag

ie/ ptr’s and structures that can be used to write to a mb

not impossible but not trivial

[quote=438834:@Norman Palardy]this is exactly why the new framework has an immutable one
[/quote]

But then to be efficient you have to know at least about what size you would need and that is not always knowable… or nay it bigger that you think you will ever need which defeats the goal of using as little system resources as possible.

[quote]
making the existing one support freezing would be a decent chunk of work since you’d have pt make sure that every other way to access & write to the memoryblock respected the “frozen” flag

ie/ ptr’s and structures that can be used to write to a mb

not impossible but not trivial[/quote]

Of course they could just trust we won’t modify the content… but I know that won’t happen…

This feature request may not ever be implemented, but I think it could be a big help in writing faster more and efficient code in Xojo when needed if it was.

I think there is a feature request for an immutable memoryblock super class.
So instead of new classes, just add a new super class to have only read only methods.
And that one could share bytes with string on conversation.

[quote=438836:@Karen Atkocius]@Norman Palardy this is exactly why the new framework has an immutable one
But then to be efficient you have to know at least about what size you would need and that is not always knowable… or nay it bigger that you think you will ever need which defeats the goal of using as little system resources as possible.

[/quote]

I wa snot thinking clearly when I responded. Actually for what I want to do an immutable memoryblock would be useless even if I knew the size I needed upfront as I could not write to it…

For some specific cases, to get the best possible performance, xojo either needs to trust us not to change a mutable memoryblock (it is supposed to be an “advanced” feature) , or support “freezing” a mutable memoryblock.

  • karen

[quote=438846:@Christian Schmitz]I think there is a feature request for an immutable memoryblock super class.
So instead of new classes, just add a new super class to have only read only methods.
And that one could share bytes with string on conversation.[/quote]

That only solves half the problem (though it would be worthwhile)

The other half is that is there is no truly efficient way (RAM Wise at least) to build a large string incrementally because of immutability…

There is always duplication be it from the conversion of a mutable memoryblock to a string or having to have all the individual string parts in an array and using joint make the full string. There is always at least 100% byte overhead. (more for string arrays as I’m sure each string uses more bytes that it’s content)

A mutable memoryblock which could be “frozen” solves this issue…

BTW assigning a string to a Freezeable MemoryBlock would be done like this
Dim MB as New MemoryBlock(aString)

Which would immediately set the Freeze flag and so allow the bytes not to have to be copied to be accessible by Memoryblock and BinaryStream methods…

All in all IMO a relatively simple and straight forward API solution to the limitations we have now… (But I don’t know how hard it would be to make it work under the hood)

  • karen

there would be a lot of current code that would have to be modified to enable “freezing”

  • ptr access to the memoryblock in every case
  • anything in the plugin sdk that might access a memoryblock (and since this can be done via a pointer in the plugins C code I’m not sure how you’d force it to be immutable since its just a pile of bytes and the “frozen” flag could easily be ignored there)
  • the runtimes themselves

I’m not convinced that its possible to cover all the use cases

We solved it over 15 years ago with the StringHandleMBS class in MBS Xojo DataTypes Plugin.

I’m glad I don’t have to convince you! :wink:

  • karen

oh i know there are other languages that have something like this and noted that on the case
I just think it will be such a decent sized job for a very limited payoff that its unlikely to occur

[quote=438967:@Norman Palardy]oh i know there are other languages that have something like this and noted that on the case
I just think it will be such a decent sized job for a very limited payoff that its unlikely to occur[/quote]

In the long run I think the payoff would be bigger than you think… It would make some things a lot more practical to do in Xojo that now need a plugin… but admittedly it would take awhile for people to start using the capability

  • karen

lets just say that I remain skeptical

BTW I did not know other languages had that feature… I just saw it as a solution to a problem I want to solve!

  • karen

what I dont know is how, or if, they hand such a block / instance off to something external like a plugin and whether it remains immutable there

in theory there’s is no way to enforce that because is you had a memory block off you mostly hand off a ptr to bytes as far as I know and then what got called can do what it wants