MongoDB 3.0 WiredTiger compression results

julian

Templates.js is really slow at parsing templates.

#shotsfired

In @psychobunny's defence, he and @baris have been working quite hard to get parsing speed up, especially leading up to v0.9.0... there may be a couple jsfiddles comparing ops/s somewhere...

scottalanmiller

Grabbing popcorn.

scottalanmiller

@AOKP said:

@scottalanmiller but not faster than Redis as a matter of fact.

I wouldn't expect it to be. Redis is all about speed at any cost. MongoDB is more about scaling and stability.

julian

"Speed at any cost" doesn't sufficiently describe antirez' approach to development. I believe he honestly has data persistence as a primary concern when designing Redis.

Objectively:

Both Redis and Mongo store data in memory
Redis stores the entire data set in memory, and persists to disk regularly
MongoDB stores recently accessed data in memory, as well as any new data, before eventually writing it to disk

Even saying "eventually writing it to disk" sounds like Mongo is careless with data, but again, I want to stress here that although neither MongoDB or Redis writes are atomic in nature, Mongo writes will make it to the disk pretty damn quickly, unless your machine is under heavy load, in which case it may be behind a little bit, but eventually will flush to disk.

? Offline

@scottalanmiller wrong.
As I explained before Redis and MongoDB have 2 different goals.

You should always go with Redis, if you are able to store your data (key-value) properly sorted, while MongoDB is good if you do not know how far your project will go and how its data will be stored:
http://stackoverflow.com/questions/5400163/when-to-redis-when-to-mongodb

And how can Redis be "performance at any cost"? Thanks to RDB and AOF, your database is pretty secure. However, please note that RDB might lose a few minutes data, which you can prevent by setting fsync for AOF to every second. Performance differences will be slightly slower, but thats all.

PitaJ

@julian well, those perf improvements had better include compiling templates into JS functions, or I'm gonna be disappointed.

<baris>

@pitaj said:

@julian well, those perf improvements had better include compiling templates into JS functions, or I'm gonna be disappointed.

@psychobunny mentioned he wants to do this, no clue how the implementation will look like though.

PitaJ

@baris something like this:

Templates.compile = function (template){
  var fnsrc = "";
  // magic to convert the template into the source of a JS function
  return fnsrc;
};
// you can write that to a JS file and use r.js to load it or what have you

// then just call the function with the data to parse it

var header = require(headertpl);

var html = header({
  user: {}
  etc
});

You could even add a custom require method to automatically compile templates when they are required.

psychobunny

This is on my to do list

// magic to convert the template into the source of a JS function

I just have to write

// TODO magic

psychobunny

The other thing I will be working in parallel is a syntax checker on compilation, so it will break (warn on prod) on NodeBB start if you do something silly. Until now we've been compensating for bad syntax on each render which obviously makes no sense at all.

This was one of our major optimizations for 0.9, we'll get the next one out as soon as I get our current nbb "behind the scenes" project finished.

wellenreiter

This post is deleted!

<baris>

@pitaj said:

// magic to convert the template into the source of a JS function

Haha yeah this is easier said than done.

Andrea Cardinale

This post is deleted!