Hello World Benchmarks for Nodejs Web Frameworks
Since I am releasing spludo pretty soon, I wanted to check out how performance is against other web frameworks for node.js.
To keep it fair (and little expressive) I just took the hello world application from each framework and benchmarked those with apache benchmark.
Concurrency Level: 256
Results:
2
3
4
5
expressjs: 3998.17 [#/sec]
(fab): 6588.95 [#/sec]
picard: 4648.41 [#/sec]
spludo 6780.38 [#/sec]
Concurrency Level: 1
Results:
2
3
4
5
6
expressjs: 2744.79 [#/sec]
(fab): 4271.43 [#/sec]
picard: 4755.03 [#/sec]
spludo: 3866.12 [#/sec]
The source code for all sample applications may be found at the public gist post.
The Test PC was a i7-920 Quadcore with HT and 8GB DDR3 RAM and a single node.js instance running.
Why <!-- beats <![CDATA[ for inline javascript
I guess everyone knows, that using:
2
3
myMagicFunction("This & That");
</script>
is pretty bad practice. The issue is, that the & should be escaped and read as & instead.
If you are reading this code with an Ajax-Request and it contains for instance unescaped & character, it will fail to load the xml properly and also fail executing the embedded javascript.
The workaround I see pretty often is the following (even suggested by w3schools):
2
3
4
5
<![CDATA[
myMagicFunction("This & That");
]]>
</script>
a better way is of course:
2
3
4
5
// <![CDATA[
myMagicFunction("This & That");
// ]]>
</script>
because it does not break any backwards compatibility to browsers, who do not get the cdata tag when in non xml mode.
This solution has one big problem: This claims the inner content to be included at this point and be escaped automaticly. And this valid html will be made visible to search engines.
Since I don't want anyone to count this comments as content for my website I am using the following solution for ages:
2
3
4
5
// <!--
myMagicFunction("This & That");
// -->
</script>
It works like a charm. If you are still using any of the previous solutions, please consider this solution as a replacement.
DJson 1.6.2 released
Today I have an important little bugfix release for djson available.
The issue was, that reading a value after an invalid set, breaks the reading. Thus, if you did a djInt on a value, which does not exist, any later dj call does not work. Thanks to Raphinity for reporting the issue.
Zamaroht reported a strange issue, when setting a value between two append-operations. This was due to a problem with the caching algorithm and has been resolved! Thanks Zamaroht for the report!
Another problem occurred, when you tried to write a string containing " (quotation marks). Those are escaped now properly, too.
These issue are of course fixed with the latest version djson 1.6.2 download.
Enhanced API Browser for node.JS
Today I created a little (~450loc) extension for the official node.JS api page. It's a client side Live-Search: filters over content and navigation as you type.
Feel free to try it out at http://dracoblue.net/showcase/enhanced-node-api/.
This is made 100% javascript (with jquery) and does not change the api.html at all.
Source is available at enhanced-node-api@github.
Comments appriciated!
bash tip: for each line in a file
When you want execute an action on a set of files (all, which contain testfile), this technique is pretty straight forward:
2
3
4
do
rm "$line"
done
But this actually does not work, if the file name contains spaces!
In this cases the "while read"-construct is failsafe:
2
3
4
do
rm "$line"
done
What's faster: JSON.parse+stringify or extend/mixin?
Today I ran into the case, that I just wanted to clone a plain javascript object (no functions at all, just values). I was wondering whether it would be faster to use the native JSON.stringify+parse (which would include generating a very big string, just to throw it away):
or to use the javascript functions process.mixin/extend and perform a deep copy:
Here are the results:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
8691ms 3x JSON.parse(JSON.stringify(object))
5839ms 3x extend(true, {}, object)
JSON-String: 29959 characters
10305ms 3000x JSON.parse(JSON.stringify(object))
7445ms 3000x extend(true, {}, object)
JSON-String: 249 characters
214ms 3000x JSON.parse(JSON.stringify(object))
94ms 3000x extend(true, {}, object)
JSON-String: 39 characters
118ms 3000x JSON.parse(JSON.stringify(object))
32ms 3000x extend(true, {}, object)
The script is the following: http://gist.github.com/354628 and the Test PC was a i7-920 Quadcore with HT and 8GB DDR3 RAM.
In my test setup it was 2x faster to use a function like extend.
