Encode/DecodeBase64 in iOS?

Great minds reside in the same gutter…er…think alike. I plan on trying with shorter blocks. I was using 1 MB blocks. I’ll try something smaller to see if I can get it to work.

I’ll report back.

I think the new Memoryblock is way more efficient so this isn’t necessary anymore. That’s why there’s a MutableMemoryBlock and regular MemoryBlock.

You could use the MutableMemoryBlock, and if you need to go from Text to data, use TextEncoding.UTF8.TexttoData which is the closest equivalent to StringValue.

But I shall think none of the methods posted in this thread really need any modification as they are ; just to be wrapped in another method that does the chunking, and uses the existing encodeBase64 (maybe renamed) to encode each 57 bytes block and pack them into a file.

If I understand it correctly (and it’s certainly possible that I don’t since the new framework is, well, new), TextToData will end up creating a new MemoryBlock, not reusing the same one. If Bob is right about efficiency, this might not matter, but in the old framework, that can slow things down dramatically as the MemoryBlock objects are repeatedly created and destroyed. (Not that I speak from experience or anything. :slight_smile: )

Only benchmarks can tell. That said, StringValue was probably doing the same under the hood.

TextToData does create a new MemoryBlock every time it’s called, though it’s not an API guarantee.

I can tell you that I’ve sped up methods from minutes to seconds by switching to reusable MemoryBlocks and StringValue. :slight_smile:

Proof is in the pastry :wink:

[code]Sub Action()
dim s as string = “MemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlockMemoryBlock”
dim depart as double = Microseconds
dim mb as new memoryblock(len(s))
System.debuglog str(Microseconds-depart)
mb = s

if 1 <> 2 then
using xojo.core
dim t as text = s.ToText
depart = Microseconds
dim mb2 as new MutableMemoryBlock(Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t))
System.debuglog str(Microseconds-depart)
end if
End Sub
[/code]

6.299995 microseconds with old stringvalue implicit conversion
7.498001 microseconds with a MutableMemoryBlock constructor and ConvertTextToData

First iteration (click) started at 57.786 and 51.85101, then 13.181 and 14.384, after which it stabilized around the above values.

The new API is a bit more than one microsecond slower. Is that really significant ? Maybe for 1000000 iterations …

Um… Shouldn’t this line dim mb2 as new MutableMemoryBlock(Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t))
be
dim mb2 as MutableMemoryBlock = Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t)

ConvertTextToData brings back a MemoryBlock to begin with, so you’re creating 2 memory blocks, no?

[quote=159978:@Bob Keeney]Um… Shouldn’t this line dim mb2 as new MutableMemoryBlock(Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t))
be
dim mb2 as MutableMemoryBlock = Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t)

ConvertTextToData brings back a MemoryBlock to begin with, so you’re creating 2 memory blocks, no?[/quote]

That won’t work. ConvertTextToData returns a MemoryBlock, which you cannot assign directly to a MutableMemoryBlock.

As far as I understand it, the MemoryBlock returned by ConvertTextToData exists only at the moment it is used for the MutableMemoryBlock construction. It is not the same as constructing a new one. Just like other methods return a string that exists only when the method is called.

Sorry, I meant to write this as

dim mb2 as MemoryBlock = Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t)

I believe it will be faster. Of course it depends on what you’re doing with it but I believe a plain memoryBlock is faster than a Mutable one.

[quote=159986:@Bob Keeney]Sorry, I meant to write this as

dim mb2 as MemoryBlock = Xojo.Core.TextEncoding.UTF8.ConvertTextToData(t)

I believe it will be faster. Of course it depends on what you’re doing with it but I believe a plain memoryBlock is faster than a Mutable one.[/quote]

Yes. I just tried. It is about one microsecond faster on average. Though on Mac it is a surprising how response times vary from one click to another. Sometimes the old framework is faster by a few decimals, sometimes it is the new one.

So your hypothesis is right. A MutableMemoryBlock is slower. But one microsecond or so is frankly not a lot, and a MutableMemoryBlock is far more flexible.

[quote=159836:@Michel Bujardet]
I just hope garbage collection is efficient[/quote]

There’s no garbage collection in Xojo

[quote=159917:@Bob Keeney]Great minds reside in the same gutter…er…think alike. I plan on trying with shorter blocks. I was using 1 MB blocks. I’ll try something smaller to see if I can get it to work.

I’ll report back.[/quote]

Say, what were the results?

Oh man. Those brain cells went on vacation back in January. I think I got it to work? Sadly, I accidentally deleted the project so I can’t double check on it.

I was told by Geoff that an immutable memory block is dramatically more efficient than a mutable one. I’d expect you’d see more of a difference actually using the memory block, not just in allocation time.

Actually, it’s more efficient in terms of memory use savings and doesn’t really have any difference in terms of access. Being able to pass around immutable chunks of data lets us just reference internal data and avoid having to copy it on the off chance someone might modify it.

Ah, thanks for clearing that up.

Impprtant: The code I posted above is buggy and should not be used as-is. I will be posting my M_Text module soon that includes the correct code.

I wrote the posted code before I understood the difference between Text and String, and as such, it won’t handle characters with a code point > 127 properly. The new version will take a MemoryBlock instead of Text as the parameter and will include a second convenience method that will take Text and a specified encoding. Decode will decode to a MemoryBlock, or to Text using a specified encoding.

It kind of feels like there should be a Xojo.Core.TextEncoding class to do this. Also for Hex.