Skip to content

N-API#90

Merged
artemp merged 25 commits intomasterfrom
n-api
Jan 25, 2019
Merged

N-API#90
artemp merged 25 commits intomasterfrom
n-api

Conversation

@artemp
Copy link
Copy Markdown
Contributor

@artemp artemp commented Oct 25, 2018

No description provided.

@artemp artemp self-assigned this Oct 25, 2018
@artemp artemp requested review from e-n-f and mapsam October 25, 2018 15:30
Copy link
Copy Markdown
Contributor

@e-n-f e-n-f left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am no expert on native Node bindings, but it looks reasonable to me

@springmeyer
Copy link
Copy Markdown
Contributor

springmeyer commented Oct 29, 2018

This looks great @artemp - The next steps in my mind would be:

  • are there any performance differences? If so, can they be mitigated?
  • getting the binary build/publish to work so that we can publish based on NAPI version and have future compatibility.

Copy link
Copy Markdown
Contributor

@mapsam mapsam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@artemp this looks pretty great! Thanks so much for running through this port. Per @springmeyer's suggestion - you should be able to run benchmarks with the steps listed at https://github.com/mapbox/vtcomposite#benchmarks. Once those are run, mind posting the results from master and this branch?

I'll start working on the vtquery port as well, to get a better sense of the N-API flow.

Comment thread src/module.cpp Outdated
#include "vtcomposite.hpp"
#include <nan.h>
#include <napi.h>
#include <uv.h>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading a little about guaranteed ABI stability across major node versions and it includes <uv.h> as one of the ports that does not guarantee stability. And then continues to say, if you want a stable napi include, to use #include <node_api.h> - Will this be an issue?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#include <napi.h> is a correct header from c++ wrapper : https://github.com/nodejs/node-addon-api/blob/master/napi.h
But, I removed #include <uv.h> as we shouldn't use it, thanks.

Comment thread src/module_utils.hpp Outdated
*/
inline void CallbackError(std::string message, v8::Local<v8::Function> func)

inline Napi::Value CallbackError(std::string const& message, Napi::CallbackInfo const& info, Napi::Function const& func)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious question: do the https://nodejs.org/api/n-api.html#n_api_n_api_callback_types types come into play here?

Comment thread binding.gyp
# cflags (linux) and xcode (mac)
'system_includes': [
"-isystem <(module_root_dir)/<!(node -e \"require('nan')\")",
"-isystem <!@(node -p \"require('node-addon-api').include.slice(1,-1)\")",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@artemp what's the need for slicing the include instead of using

"<!@(node -p \"require('node-addon-api').include\")"

?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mapsam this is the only way I found that works for me. The above expansion has too many quotes. Pls, suggest workaround, it's probably lack JS knowledge on my behalf.

@artemp
Copy link
Copy Markdown
Contributor Author

artemp commented Oct 30, 2018

@mapsam @springmeyer

N-API

time node bench/bench.js --iterations 50 --concurrency 1 --package vtcomposite --compress

1: single tile in/out ... 289 runs/s (173ms)
2: two different tiles at the same zoom level, zero buffer ... 25 runs/s (1985ms)
3: two different tiles from different zoom levels (separated by one zoom), zero buffer ... 26 runs/s (1960ms)
4: two different tiles from different zoom levels (separated by more than one zoom), zero buffer ... 27 runs/s (1885ms)
5: tiles completely made of points, overzooming, no properties ... 1389 runs/s (36ms)
6: tiles completely made of points, same zoom, no properties ... 1111 runs/s (45ms)
7: tiles completely made of points, overzoooming, lots of properties ... 820 runs/s (61ms)
8: tiles completely made of points, same zoom, lots of properties ... 345 runs/s (145ms)
9: buffer_size 128 - tiles completely made of points, same zoom, lots of properties ... 333 runs/s (150ms)
10: tiles completely made of linestrings, overzooming and lots of properties ... 397 runs/s (126ms)
11: tiles completely made of polygons, overzooming and lots of properties ... 167 runs/s (299ms)
12: tiles completely made of points and linestrings, overzooming and lots of properties ... 3571 runs/s (14ms)
13: buffer_size 128 - tiles completely made of points and linestrings, overzooming and lots of properties ... 4167 runs/s (12ms)
14: tiles completely made of points and linestrings, overzooming (2x) and lots of properties ... 5556 runs/s (9ms)
15: tiles completely made of polygons, overzooming and lots of properties ... 515 runs/s (97ms)
16: tiles completely made of polygons, overzooming (2x) and lots of properties ... 962 runs/s (52ms)
17: buffer_size 4096 - tiles completely made of polygons, overzooming (2x) and lots of properties ... 526 runs/s (95ms)
Note: pass --mem to track memory usage
Benchmark iterations: 50 concurrency: 1

real	0m7.267s
user	0m7.360s
sys	0m0.089s

NAN

time node bench/bench.js --iterations 50 --concurrency 1 --package vtcomposite --compress

1: single tile in/out ... 289 runs/s (173ms)
2: two different tiles at the same zoom level, zero buffer ... 25 runs/s (2003ms)
3: two different tiles from different zoom levels (separated by one zoom), zero buffer ... 26 runs/s (1945ms)
4: two different tiles from different zoom levels (separated by more than one zoom), zero buffer ... 27 runs/s (1875ms)
5: tiles completely made of points, overzooming, no properties ... 1316 runs/s (38ms)
6: tiles completely made of points, same zoom, no properties ... 1136 runs/s (44ms)
7: tiles completely made of points, overzoooming, lots of properties ... 833 runs/s (60ms)
8: tiles completely made of points, same zoom, lots of properties ... 345 runs/s (145ms)
9: buffer_size 128 - tiles completely made of points, same zoom, lots of properties ... 345 runs/s (145ms)
10: tiles completely made of linestrings, overzooming and lots of properties ... 400 runs/s (125ms)
11: tiles completely made of polygons, overzooming and lots of properties ... 167 runs/s (299ms)
12: tiles completely made of points and linestrings, overzooming and lots of properties ... 4167 runs/s (12ms)
13: buffer_size 128 - tiles completely made of points and linestrings, overzooming and lots of properties ... 4167 runs/s (12ms)
14: tiles completely made of points and linestrings, overzooming (2x) and lots of properties ... 5000 runs/s (10ms)
15: tiles completely made of polygons, overzooming and lots of properties ... 515 runs/s (97ms)
16: tiles completely made of polygons, overzooming (2x) and lots of properties ... 962 runs/s (52ms)
17: buffer_size 4096 - tiles completely made of polygons, overzooming (2x) and lots of properties ... 521 runs/s (96ms)
Note: pass --mem to track memory usage
Benchmark iterations: 50 concurrency: 1

real	0m7.387s
user	0m7.488s
sys	0m0.064s

@artemp artemp merged commit c3a0f11 into master Jan 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants