Memoryblock Question

General
#1

Hi there,

in my App I’ve got a Subclass of the UDPSocket. The Socket has the following in its DataAvailable Handler + some condition checking, not shown here:

[code] Dim d As Datagram
Dim mb As MemoryBlock

d = Me.Read // Read Datagram as soon as it is available
mb = d.data // Read Datagram into a MemoryBlock so we can parse it Bytewise
mPacketsReceived = mPacketsReceived+1
mPacketsSent = mPacketsSent +1

mReceivedPacket ( mb, d.Address )[/code]

The function mReceivedPacket does this:

MyClass(mb.uInt16Value ( 14 )).mb = mb DataReceived(Address, MyClass(mb.uInt16Value ( 14 ))) //Firing Event Handler

The dataAvailable Handler beforehand checks if several conditions have been met, so its save to assume that uInt16Value(14) is what it needs to be.

MyClass is doing the folliwing the setter of the mb variable:

[code] if value <> mmb then

mmb = value
setValues.Run

end[/code]

Whereas setValues is a Thread. This all works well, despite the fact that in mReceivedPacket the line “MyClass(mb.uInt16Value ( 14 )).mb = mb” takes up to 4ms, and thus prevents the dataAvailable from being able to fire as fast as it would need to be, which in return means the delay is adding up until packets get lost because the buffer of the UDPSocket runs full.

Now and finally… My question:

Why is this taking so long? Because it is not pointing to the original MB, but instead creating a new instance, or at least assigning a new value to a different instance of the memoryblock?
And what could I do to avoid this issue?

Cheers and thanks once again, you guys rock!

Denis

#2

I doubt that could take that long. How are you doing that timing? If you are using the Profiler, it’s known to give misleading results when timing threaded code.

#3

Yes, with Profiler, but actually it is the line MyClass(mb.uInt16Value ( 14 )).mb = mb taking that long. As soon as I comment this one out, it is all good and fast (obviously). Since this one is not threaded yet, I doubt the profiler is doing wrong stuff… :slight_smile:

#4

It also takes the same amount of time if the setter is just doing

    mmb = value

and not even starting the thread…

#5

What happens if you comment out the comparison if value <> mmb then?

#6

Hi Kem,

Even if I comment out everything in the setter except mmb = value it still takes up to 4ms average. :-/

#7

I wonder if the conversion from UInt16 to Int32 (Integer) is making a difference? What if you rewrite you code this way?

  dim index as Integer = mb.UInt16Value( 14 )
  dim c as MyClassClass = MyClass( index )
  c.mb = mb
  DataReceived(Address, c) //Firing Event Handler

I really wouldn’t expect this to make much difference, but you never know.

#8

Actually, that makes a huge difference… I also implemented a Property in myClass “isRequested as Boolean” - so the thread doesnt start to run unless I really need that data. Now average time went down to 0.5ms… Sometimes it seems to be the things you dont think that should be an issue…

Thanks for pointing me into that direction… :slight_smile:

#9

That doesn’t make much sense to me - a uint16 to uint32 conversion of a single value is going to be blindingly fast, so I can’t see how you are getting an 8x speedup.

if you really want an accurate speed measurement, do this:

  dim t0 as double = microseconds
  ... code you want to measure...
  dim deltaT as double = microseconds - t0
  system.debuglog "That took " + str(deltaT) + " microseconds"
#10

I wonder if it’s more in looking up the object from the array only once.

#11

doesnt seem to be, its much quicker now… for whatever reason - Ill investigate more on this once I’ve pushed the beta out the door…

#12