Normally, the Node.js process will exit when there is no work scheduled (docs). You shouldn’t call process.exit() unless it is necessary to terminate the Node.js process immediately due to an error condition. Calling process.exit() doesn’t let pending events to complete which may lead to unpredictable results as demonstrated in the docs.
Now that we know how to naturally terminate a Node.js application, how do we achieve it if we are using the Firebase JavaScript SDK?
First you need to cancel any asynchronous listeners. For example, if you subscribed for data changes, you need to unsubscribe:
let func = firebase.database().ref(userDB).on("value", myHandler);
...
firebase.database().ref(userDB).off("value", func);
Some people suggest that you also call firebase.database().goOffline() in the final stage.
Additionally, as described in these bug reports (#1 and #2), if you used firebase.auth() you need to call firebase.auth().signOut().
And finally, you also need to destroy the Firebase application by calling app.delete().
This has worked for me using Node.js version 10 and Firebase JS SDK version 8.
The benchmarks here do not try to be complete, as they are showing the performance of the languages in one aspect, and mainly: loops, dynamic arrays with numbers, basic math operations.
This is an improved redo of the tests done in previous years. You are strongly encouraged to read the additional information about the tests in the article.
The big difference this time is that we use a slightly modified benchmark method. Programs are no longer limited to just 10 loops. Instead they run for 90 wall-clock seconds, and then we divide and normalize their performance as if they were running for only 10 loops. This way we can compare with the previous results. The benefit of doing the tests like this is that the startup and shutdown times of the interpreters should make almost no difference now. It turned out that the new method doesn’t significantly change the outcome compared to the previous benchmark runs, which is good as the old way of benchmarks seems also correct.
For the curious readers, the raw results also show the maximum used memory (RSS).
Brief analysis of the results:
Rust, which we benchmark for the first time, is very fast. 🙂
C# .NET Core on Linux, which we also benchmark for the first time, performs very well by being as fast as NodeJS and only 78% slower than C++. Memory usage peak was at 230 MB which is the same as Python 3.5 and PHP 7.0, and two times less than Java 8 and NodeJS.
NodeJS version 4.3.x got much slower than the previous major version 4.2.x. This is the only surprise. It turned out to be a minor glitch in the parser which was easy to fix. NodeJS 4.3.x is performing the same as 4.2.x.
Python and Perl seem a bit slower than before but this is probably due to the fact that C++ performed even better because of the new benchmark method.
Java 8 didn’t perform much faster as we expected. Maybe it gets slower as more and more loops are done, which also allocated more RAM.
Also review the analysis in the old 2016 tests for more information.
The tests were run on a Debian Linux 64-bit machine.
Update @ 2016-10-15: Added the Rust implementation. The minor versions of some languages were updated as well. Update @ 2016-10-19: A redo which includes the NodeJS fix. Update @ 2016-11-04: Added the C# .NET Core implementation.
The benchmarks here do not try to be complete, as they are showing the performance of the languages in one aspect, and mainly: loops, dynamic arrays with numbers, basic math operations.
This is a redo of the tests done in previous years. You are strongly encouraged to read the additional information about the tests in the article.
The clear winner among the script languages is… PHP 7. 🙂
Yes, that’s not a mistake. Apparently the PHP team did a great job! The rumor that PHP 7 is really fast confirmed for this particular benchmark test. You can also review the PHP 7 infographic by the Zend Performance Team.
Brief analysis of the results:
NodeJS got almost 2x faster.
Java 8 seems almost 2x slower.
Python has no significant change in the performance. Every new release is a little bit faster but overall Python is steadily 15x slower than C++.
Perl has the same trend as Python and is steadily 22x slower than C++.
PHP 5.x is the slowest with results between 47x to 60x behind C++.
PHP 7 made the big surprise. It is about 10x faster than PHP 5.x, and about 3x faster than Python which is the next fastest script language.
The tests were run on a Debian Linux 64-bit machine.
