Curious is an array of MemoryBlocks of 4 bytes each similar in overhead to an array of Int32? Most of the time I use the Int32 I’m putting it into a MB and accessing the bytes so I thought maybe changing the array type might be better, but it could get rather large. (maybe 1 gig)
not sure, but I’d think an array has more overhead than a MB, since the array needs to have a structure to define itself… and an MB is just a block of bytes, with the developer having to decide what those bytes “mean”
Well there’s an idea a MB that’s accessible by Counter * 4 to get my Int32
For counter as integer = 0 to mb.size - 1
Dim i As Integer = mb.Int32Value(counter*4)
Next
HOw big a structure are you talking, that you are worried about a few hundred or so bytes of overhead?
could be a gig, depends on the file size, it’s encryption that needs the whole thing loaded in at once. Though I doubt I’d even load more than a 10 megabyte file size.
If you’re looking for speed use a Ptr to the MemoryBlock.
dim m As new MemoryBlock( OneGig )
dim p As Ptr = mb
//now use p for read and write
I believe only classic Memory can be converted to a Ptr. Also, the Ptr reads and writes in the native endianness of the machine regardless of the setting on the MemoryBlock from which it came.
Xojo.Core.MemoryBlock and Xojo.Core.MutableMemoryBlock have PtrValue.
But somehow, string is probably friendlier to use with Classic MemoryBlock.
It should not be very different for Integers.
Since you’ll get the best performance by reading the file in all at once, leave it as a memoryblock and access it directly. Any of the following will result in very poor performance:
- read the file 4 bytes/1 integer at a time
- break the file into an array of integers
- break the file into an array of 4-byte memoryblocks
Thanks all, and as for the substitute tables, I think I’ll put them in memoryblocks too as there is a lot of packing and unpacking of bytes that won’t need to be done as I’ll have direct access to the bytes and not have to unpack Int32 to bytes, manipulate the bits then in the Files memoryblocks then pack the Int32 again and, and, and …
PtrValue is for reading data within the MemoryBlock. To convert the new MemoryBlocks to Ptr call it’s Data property. Even the regular non-mutable MemoryBlock is modifiable through a Ptr.
You can get the pointer, but mutating it is definitely unsupported and will die
sometimes
I would not do this
Even for a MutableMemoryBlock?
That’s fine. It’s just an immutable memory block that has undefined behavior if you modify what the pointer points at.
I meant specifically your reference to [quote=298909:@Will Shank]Even the regular non-mutable MemoryBlock is modifiable through a Ptr.[/quote]
and mutating an immutable memory block via a ptr access