libui-napi
libui-napi copied to clipboard
parro-it
Comparison between libui-node & libui-napi
I completed the initial implementation of windows, boxes and multiline entry. I then created a new branch from 0_3_0 branch of libui-node, removed all the stuff except windows, boxes and multiline entry. Here is a comparison of the two implementation to help decide if the N-API rewrite is worth the effort:
nbind version
binary size: 627Kb compilation time: 39s runtime memory consuption of example.js: 21M
N-API version
binary size 56Kb compilation time: 7s runtime memory consuption of example.js: 18M
Considering also that N-API greatly simplify publish of prebuilt binaries, and that it offer much control on memory management and type conversion, my opinion is that the conversion it's totally worth the effort.
You mean at API level? It's pretty good
You can compare https://github.com/parro-it/libui-node/blob/0_3_0/examples/example-from-napi.js and https://github.com/parro-it/libui-napi/blob/master/example/using-classes/index.js
Are you concerned on getting support for older versions?
(Most likely not worth it.)
It works with node >=8
https://github.com/parro-it/libui-napi/blob/ee33206ad8403fed98dded96f8c687c1ffc863de/package.json#L19-L21
Well..
Regarding how to organize the development, I'm in doubt if it would be better to move all the stuff I already did here to a new branch in libui-node, or otherwise keep libui-napi as a separate repo and use libui-node only for the wrapper classes. Any thought?
These: https://github.com/parro-it/libui-napi/tree/master/js The native part now bind libui functions one-by-one, and these classes should provide the same API as previews release.
Any thought?
Not sure. Everything being in one place might make development easier.
What about linux and windows?
Windows doesn't like the _Atomic(bool) syntax.
Linux doesn't know pthread_rwlock_t.
Everything being in one place might make development easier.
Yes, I agree.
Windows doesn't like the _Atomic(bool) syntax.
By now, I removed the _Atomic altogether... I should think of a better solution...
Linux doesn't know pthread_rwlock_t.
Are we using it?
Are we using it?
No, it's used in uv.h and was fixed by changing -std=c11 to -std=gnu11.
No, it's used in uv.h and was fixed by changing -std=c11 to -std=gnu11.
Now I get the reason for that change...
The Atomic usage could probably be replaced by some other thread synchronization function implemented by libuv
Now I get the reason for that change...
Took quite a while to find that on the internet.
Took quite a while to find that on the internet.
I guess, there is no much documentation or example around...
I have a collection of bookmark on some reference related to node event loop and libuv docs / example / article. How could I share them?
https://gist.github.com/parro-it/842ff46a86142c30b1f94f97bb738418 The titles are not saved unfortunatly... âšī¸
Are you concerned on getting support for older versions?
N-API is now available in Node 6.14.2. If we want to, these changes would be required:
- use the polyfill for async-hooks (the official creditkarma/async-hooks - mine isn't needed).
- async and await aren't supported đ (in the download scripts).
N-API is now available in Node 6.14.2.
Awesome! Is that a new release where they backported N-API or what?
async and await aren't supported đ (in the download scripts).
We can change that stuff, not a great deal...
(the official creditkarma/async-hooks - mine isn't needed)
If I remember correctly, using your we can support node 4?
If I remember correctly, using your we can support node 4?
Ah no, because it doesn't have N-API I guess...
Awesome! Is that a new release where they backported N-API or what?
Exactly.
If I remember correctly, using your we can support node 4?
Ah no, because it doesn't have N-API I guess...
Exactly. đ
Why is the library file called node_libui.node while this will be called "libui-node"?
Why is the library file called node_libui.node while this will be called "libui-node"?
Uhm, no reason...
After 21 days of work, the port is almost complete, so I thought to repeat the comparison with the full version of [email protected]
nbind version binary size: 627Kb compilation time: 39s runtime memory consuption of example.js: 21M
N-API version binary size 3,0M compilation time: 234s runtime memory consuption of example.js: 19M
prebuilt binaries are now available for linux, windows & macOS 32bit. Maybe we should support also for 32bit versions?
Also the structure of the repo (folders, files, tools) should be almost stable, so I think we could merge back this repo into a new branch 0_4_0 on libui-node as soon are tester branch is merged
Maybe we should support also for 32bit versions?
Not needed for macOS. How many 32bit Windows and Linux users are there?