[mraleph]

> I have the following methods (via macro defs) in my "native extension":

Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods.

> - Dart developers does not like annotation

I like annotations!

> - Dart VM executes custom "native (which in fact are very fast)" methods very slow

This concern is very valid: it is true that transition between Dart code and native methods is too heavyweight and as a developer you have no way to fix it yourself. We had plans to fix it eventually - but they never been very high on the list of things.

Did you file a bug for the slowness of your native extension?

[mezoni]

>> Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods.

I work on integrating into Dart ecosysem "foreign functions interface" (ffi).

External typed data is not suitable in many cases:

- Does not provide physical storage address to use code (binary interop requires that)

- I don't need it because it heavyweight if use it with C pointers and references

- It has limit in size (specified in Dart VM on max array length)

- I need malloc and typed data does not help here in any way

- I access data (by physical address) allocated externally

>> Did you file a bug for the slowness of your native extension?

This is useless. A long time ago we already did not come to a consensus.

[mraleph]

> I work on integrating into Dart ecosysem "foreign functions interface" (ffi).

Truly efficient FFI has to be part of the VM, you can't implement efficient FFI from outside.

> - I access data (by physical address) allocated externally

Do you really mean "physical address" here?

External data is created precisely to efficiently access data allocated externally, because it allows direct raw access to a given region of memory (sans bounds checking).

[mezoni]

>> Do you really mean "physical address" here?

>> External data is created precisely to efficiently access data allocated externally, because it allows direct raw access to a given region of memory (sans bounds checking).

Serach in code "Unsafe." and you understand what means "physical address" as a base and offset.

Eg.

  Unsafe.memorySet(base, offset, 0, size);
  Unsafe.memoryAllocate(size);
  Unsafe.writeInt8(base, offset, value);

https://gist.github.com/mezoni/f85b04bf19dab8333abf

[mezoni]

>> Truly efficient FFI has to be part of the VM, you can not implement efficient FFI from outside.

Evil of the "Truly efficient FFI" in that the it in many cases does not exists as such.

Benefit of "NOT Truly efficient FFI" in that the it in many cases it may be considered as acceptable in many cases (and exist in reality).

>> Do you really mean "physical address" here?

See here.

https://gist.github.com/mezoni/f85b04bf19dab8333abf