[mezoni]

>> so I don't really understand what bothers you about these lists.

This approach does not allow me to use annotations (or other way) for specifying that my own "native" methods in "native extension" are required some attention.

You use for such attention these lists.

Eg.

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

=========================

  UNSAFE_READ_INT(8, int8_t)
  UNSAFE_READ_INT(16, int16_t)
  UNSAFE_READ_INT(32, int32_t)
  UNSAFE_READ_INT(64, int64_t)
  // Skipped
  UNSAFE_READ_FLOAT(32, float)
  UNSAFE_READ_FLOAT(64, double)
  // Skipped

=========================

These methods are very fast (in C++) but in fact Dart VM executes them (native methods) very SLOOOOOOOOOOOWWWWWWWWWWWW...

See my question on stack overflow:

========================= Why native wrapped functions in Dart are such heavyweight in comparison with “DEFINE NATIVE ENTRY” functions that are very lightweight?

http://stackoverflow.com/questions/21363429/why-native-wrapp... =========================

- Dart developers does not like annotation

- Dart VM does not uses annotation

- Dart VM does not uses type annotation

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

This is what is means for me that Dart VM is not a very well balanced for high performance.

P.S.

This is why "I bothers you about these lists".

Because they are in some cases the only way to improve performance.

[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