Move sdk/lib/html/dartium/nativewrappers.dart ?

[kevmoo]

sdk/sdk/lib/html/dartium/nativewrappers.dart

Line 1 in ea6991a

// Copyright (c) 2012, the Dart project authors. Please see the AUTHORS file

Thoughts @terrylucas ? @jacob314 ?

[mraleph]

Please do not delete this file, it is in use. It can be probably moved somewhere else though.

[terrylucas]

@a-siva

Shiva with Dartium gone the file sdk/lib/html/dartium/nativewrappers.dart is only needed by the VM. I would like to move this file to sdk/lib/vmservice is that okay with you?

[terrylucas]

@mraleph

[mraleph]

vmservice is a strange location for this file, because it is not related to vmservice. In sdk/lib the best location I could think of is probably sdk/lib/_internal

[terrylucas]

That's fine with me. Siva is that okay for you?

[terrylucas]

Or could the contents of nativewrappers be added to dart:_internal and the nativewrappers.dart file then be eliminated? Since its no longer shared with Dartium.

[a-siva]

I am fine with that but also check with the analyzer folks (@bwilkerson) because I think they look for this file when analyzing sources

[kevmoo]

Feel free to rename the issue to "move" instead of delete.

…

On Mon, Feb 26, 2018 at 8:30 AM, Siva ***@***.***> wrote: I am fine with that but also check with the analyzer folks ***@***.*** <https://github.com/bwilkerson>) because I think they look for this file when analyzing sources — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32311 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABCiq0QXfR8yZzo6dm8YcGc8-n9GStNks5tYtwdgaJpZM4SSfHW> .

[Sunbreak]

We are customizing Flutter for our project, which needs some Dart-C-interop

Is it safe to use import 'dart:nativewrappers' as below?

• https://github.com/dart-lang/sdk/blob/master/sdk/lib/html/html_common/html_common.dart#L11
• https://github.com/flutter/engine/blob/62b5a53b10a12413845f6574559b4d836c57b2cb/lib/ui/ui.dart#L23

[mraleph]

Is it safe to use import 'dart:nativewrappers' as below?

I am not sure I understand the question. Can you clarify?

which needs some Dart-C-interop

If you need Dart-C interop you should use dart:ffi.

[Sunbreak]

Is it safe to use import 'dart:nativewrappers' as below?

I am not sure I understand the question. Can you clarify?

which needs some Dart-C-interop

If you need Dart-C interop you should use dart:ffi.

There is a blocker issue on dart:ffi for Xcode Archive: #43482

Non-Global Symbols is not accepted for a hybrid project with both native & flutter module

[mraleph]

Non-Global Symbols is not accepted for a hybrid project with both native & flutter module

What do you mean by "non-accepted"? You can't use it for some reason? Is it for code size or other reasons? Then we should figure a way to make FFI work for you.

/cc @dcharkes

[Sunbreak]

Code size is the main concern

[mraleph]

@Sunbreak how much larger does you IPA become if you change the option to Non-Global Symbols?

[Sunbreak]

@Sunbreak how much larger does you IPA become if you change the option to Non-Global Symbols?

The flutter module adds about 21MB to the archive of our hybrid project.
Non-Global Symbols will add another 7MB, which is too large for our benchmark of APP size

[mraleph]

@Sunbreak Thanks! That's a valuable thing to know, helps to put this into perspective and prioritise.

Just to confirm: 7MB is the change in size of the exported IPA, with thinning applied? If that's the case this is indeed quite a lot and we should certainly look for solutions.

[Sunbreak]

@Sunbreak Thanks! That's a valuable thing to know, helps to put this into perspective and prioritise.

Just to confirm: 7MB is the change in size of the exported IPA, with thinning applied? If that's the case this is indeed quite a lot and we should certainly look for solutions.

The build(with provision file) on CI is quite slow. I archive locally and get unix executable files with 234.5MB(All Symbols)，241.1MB(Non-Global Symbols)，396.7MB(Debug Symbols)

Exported IPAs may be thinner. 5MB gap is a reasonable guess

We've made a lot effort to strip flutter module and another 2MB will hit the upper limit of module size

[Sunbreak]

@mraleph

which needs some Dart-C-interop

If you need Dart-C interop you should use dart:ffi.

We use flutter/tonic for Dart-C-interop and find it quite slower than dart:ffi

dartAdd: 0.17 ms

• main.dart

  int add(int a, int b) {
    return a + b;
  }

  void dartAdd(int count) {
    print('dart start ${DateTime.now()}');
    for (var i = 0; i < count; i++) {
      add(1, 2);
    }
    print('dart end ${DateTime.now()}');
  }

ffiNativeAdd: 0.17 ms

• native_add.dart

final DynamicLibrary nativeAddLib = Platform.isAndroid
    ? DynamicLibrary.open("libnative_add.so")
    : DynamicLibrary.process();
final int Function(int x, int y) nativeAdd = nativeAddLib
    .lookup<NativeFunction<Int32 Function(Int32, Int32)>>("native_add")
    .asFunction();

• native_add.cpp

#include <stdint.h>
extern "C" __attribute__((visibility("default"))) __attribute__((used))
int32_t native_add(int32_t x, int32_t y) {
    return x + y;
}

tonicNativeAdd: 1.18 ms

• tonic_binding.dart

int nativeAdd(int a, int b) native 'TonicBinding_NativeAdd';

• tonic_binding.cc

int32_t TonicBinding::NativeAdd(int32_t a, int32_t b) {
  return a + b;
}

Is dart:ffi ready for Dart VM? #34452

[mraleph]

We use flutter/tonic for Dart-C-interop and find it quite slower than dart:ffi

Well, that's the whole idea of why we developed FFI in the first place. It's a faster, more AOT friendly way to bind Dart to native code.

Is dart:ffi ready for Dart VM? #34452

It is ready - there are multiple projects that use it already, there are few missing pieces still (e.g. struct by value) which we are finishing right now, after that we are planning to declare "1.0" release of Dart FFI.

We also would like to address #43582 so that you could use it without penalising your code size.