The program is pretty simple.
It is a good sample of Mustache
rendering principles.
It renders a recursive template taken from a well known web site:
<h2>Example 6 : Recursively binding data to templates</h2>
<h3>Organization Structure</h3> {{> person}}
{{<person}} <div> <b>{{name}}</b> ({{title}}) <div style='padding-left: 15px; padding-top: 5px;'> {{#manages}} {{>person}} {{/manages}} </div> </div> {{/person}}
This template is executed on the following context data:
{ title : "President", name : "Perry President", manages : [ { title : "CTO", name : "Janet TechOff", manages : [ { title : "Web Architect", name : "Hari Archie", manages : [ { title : "Senior Developer", name : "Brenda Senior", manages : []}, { title : "Developer", name : "Roger Develo", manages : []}, { title : "Junior Developer", name : "Jerry Junior", manages : []} ]} ]}, { title : "HRO", name : "Harold HarOff", manages : [ { title : "HR Officer", name : "Susan McHorror", manages : []}, { title : "HR Auditor", name : "Audrey O'Fae", manages : []} ]} ]}
For SynMustache, we got:
For mustache.js over SpiderMonkey, we got:
The native Delphi version, included within our mORMot
framework, is 10 times faster than the JavaScript optimized
library.
And if you look at the process explorer during the run, SynMustache
does not have any memory increase, whereas the JavaScript engine will
continuously increase/decrease its memory usage, due to the garbage
collector...
I always prefer such benchmarks, pretty close to real world process, in
comparison to optimistic and unrealistic benchmarks like a Mandelbrot
computation.
Who is calculating a fractal for its business? Unless you write a video game
(but who may use a JIT and a GC for it?), your software will very likely
process data and strings in memory, just as with this benchmark.
In fact, JavaScript runs pretty well on
latest SpiderMonkey, with more than 10,000
recursive blocks rendered per second.
The SynMustache performance (around 120,000 recursive blocks
rendered per second) sounds so high it may not be worth it...
Just remember: 10 times faster, on a server, means 10 times more clients
served in the same time...
So 10 times more Return On Investment
(ROI) for the same hardware, and probably a more integrated (cheaper) solution,
since you won't need to spread the server software on several pieces of
hardware!
If your managers begin to have doubts about JIT/GC/Java/C# speed and ROI - which is pretty much likely after years running J2EE servers around the globe - you can show them this sample.
Today, managers may be confident that JavaScript (and mono-threaded
node.js) is the answer.
At least, they are told so.
But, even if they are far away from the technical stuff today, they know that
such solutions consume a lot of computer resources: each tab in Chrome
or FireFox exhausts their notebook or smartphone computing
power!
JavaScript may be good enough on client side, but may reduces the ROI
on servers.
RAM on servers do cost money...
Imagine how your business may benefit from a multi-threaded engine like
mORMot, when compared to a mono-threaded node.js
server...
And, in mORMot, every single thread is able to process 10 times more
data than its JavaScript version!
So 10 times more clients on the same server, 10 time less money to invest, 10
times more money to win, with the stability of native code and tuned memory
process...
I'm quite sure they will perhaps start to be moon-eyed again on
Delphi.
Especially if the company has still Delphi skilled people in its
teams.
Do not let your critical software be written by young developers who do not
know about algorithms and data structures.
Delphi has the strengths of C/C++, but easier to work with thanks to
a cleaner
approach, and all modern
design concept at hand.
OK... I stopped trolling, but it is not far away from my own experiment...
Feedback is welcome on our web site, as usual.