Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fix img urls, github changed them : (

The old urls were much nicer as they did not include my account / would
have worked in forked repos as well.

Fixes #4
  • Loading branch information...
commit 5ee2f6cdbb7b11e30346badf344f9829ee29f268 1 parent 3d7bff6
Felix Geisendörfer authored

Showing 1 changed file with 17 additions and 17 deletions. Show diff stats Hide diff stats

  1. +17 17 README.md
34 README.md
Source Rendered
@@ -18,8 +18,8 @@ node.js. Well, that's not quite true. There was [one
18 18 module](https://github.com/masuidrive/node-mysql) by [Yuichiro
19 19 MASUI](http://twitter.com/masuidrive). But unfortunately he never finished it.
20 20
21   -<img width="258" src="./faster-than-c/raw/master/figures/other/yuichiro-masui.png">
22   -<img width="698" src="./faster-than-c/raw/master/figures/other/node-mysql-original.png">
  21 +<img width="258" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/yuichiro-masui.png">
  22 +<img width="698" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/node-mysql-original.png">
23 23
24 24 However, there was something interesting about it. It was written in JavaScript.
25 25 I mean just JavaScript, no C/C++. In fact it was even crazier, because when
@@ -47,8 +47,8 @@ because it was based on strings. Anyway, over a time span of about 3
47 47 months, this code base turned into a working library called
48 48 [node-mysql](http://github.com/felixge/node-mysql) and people started using it.
49 49
50   -<img width="236" src="./faster-than-c/raw/master/figures/other/felix-geisendoerfer.png">
51   -<img width="610" src="./faster-than-c/raw/master/figures/other/node-mysql.png">
  50 +<img width="236" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/felix-geisendoerfer.png">
  51 +<img width="610" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/node-mysql.png">
52 52
53 53 But ... you know how it is in this universe. No good deed goes unpunished.
54 54 Newton already discovered this in 1687 and is now known as the third law of
@@ -71,13 +71,13 @@ something like this.
71 71 And this is what happened, [Oleg Efimov](https://github.com/Sannis) released a
72 72 new library called [mysql-libmysqlclient](https://github.com/Sannis/node-mysql-libmysqlclient).
73 73
74   -<img width="245" src="./faster-than-c/raw/master/figures/other/oleg-efimov.png">
75   -<img width="614" src="./faster-than-c/raw/master/figures/other/node-mysql-libmysqlclient.png">
  74 +<img width="245" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/oleg-efimov.png">
  75 +<img width="614" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/node-mysql-libmysqlclient.png">
76 76
77 77 His library had a few disadvantages compared to mine, but it was awesome by
78 78 being much faster:
79 79
80   -<img width="640" src="./faster-than-c/raw/master/figures/mysql-libs/pngs/a-b.png">
  80 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql-libs/pngs/a-b.png">
81 81
82 82 This, benchmarks shows the performance of parsing 100.000 rows / ~180 MB of
83 83 network data from the MySQL server.
@@ -97,19 +97,19 @@ So after I overcame my initial resignation, I set out to make my parser faster.
97 97 The current result of that is node-mysql 2.x, which can easily compete against
98 98 libmysql.
99 99
100   -<img width="640" src="./faster-than-c/raw/master/figures/mysql-libs/pngs/a-b-c.png">
  100 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql-libs/pngs/a-b-c.png">
101 101
102 102 But again, it didn't take long for the third law of Github to kick in again, and
103 103 a few months ago a new library called [mariasql](https://github.com/mscdex/node-mariasql)
104 104 was released by [Brian White](https://github.com/mscdex).
105 105
106   -<img width="237" src="./faster-than-c/raw/master/figures/other/brian-white.png">
107   -<img width="698" src="./faster-than-c/raw/master/figures/other/node-mariasql.png">
  106 +<img width="237" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/brian-white.png">
  107 +<img width="698" src="https://raw.github.com/felixge/faster-than-c/master/figures/other/node-mariasql.png">
108 108
109 109 And yet again, it was an amazing performance improvement. As you can see in this
110 110 graph, mariasql is kicking the shit out of my library:
111 111
112   -<img width="640" src="./faster-than-c/raw/master/figures/mysql-libs/pngs/a-b-c-d.png">
  112 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql-libs/pngs/a-b-c-d.png">
113 113
114 114 So fuck - maybe it's time to finally give up and accept that I cannot compete
115 115 with a well engineered C binding. C must be faster after all.
@@ -123,7 +123,7 @@ performance.
123 123 So ... I am hacking on a new parser again. And from the looks of it, it will
124 124 allow me to be as fast as the mariaqsql library:
125 125
126   -<img width="640" src="./faster-than-c/raw/master/figures/mysql2-vs-new-parser/pngs/bar.png">
  126 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql2-vs-new-parser/pngs/bar.png">
127 127
128 128 Of course, the 3rd law of GitHub would predict that this won't last very long,
129 129
@@ -298,22 +298,22 @@ no. Otherwise you end up with bullshit. In fact, all of the benchmark graphs
298 298 I have shown you so far are complete bullshit. Remember the benchmark showing
299 299 the performance of my new parser?
300 300
301   -<img width="640" src="./faster-than-c/raw/master/figures/mysql2-vs-new-parser/pngs/bar.png">
  301 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql2-vs-new-parser/pngs/bar.png">
302 302
303 303 Well, let's look at it another way. Here is a jitter plot:
304 304
305   -<img width="640" src="./faster-than-c/raw/master/figures/mysql2-vs-new-parser/pngs/jitter-annotated.png">
  305 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql2-vs-new-parser/pngs/jitter-annotated.png">
306 306
307 307 Ok, looks like we have a problem, why are there two clusters of data points
308 308 in each benchmark? Well, let's look at this data another way:
309 309
310   -<img width="640" src="./faster-than-c/raw/master/figures/mysql2-vs-new-parser/pngs/line.png">
  310 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql2-vs-new-parser/pngs/line.png">
311 311
312 312 So, it seems like performance starts out great, but then something happens and
313 313 things go to hell. Well, I'm not sure what it is yet, but I have a strong suspect.
314 314 Let's have a look at this graph showing the heap used:
315 315
316   -<img width="640" src="./faster-than-c/raw/master/figures/mysql2-vs-new-parser/pngs/heap-used.png">
  316 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql2-vs-new-parser/pngs/heap-used.png">
317 317
318 318 As you can see, it seems during the same moment our performance goes to shit,
319 319 v8 decides to give more memory to our programs before performing garbage
@@ -321,7 +321,7 @@ collection.
321 321
322 322 This can also be seen when looking at the heap total:
323 323
324   -<img width="640" src="./faster-than-c/raw/master/figures/mysql2-vs-new-parser/pngs/heap-total.png">
  324 +<img width="640" src="https://raw.github.com/felixge/faster-than-c/master/figures/mysql2-vs-new-parser/pngs/heap-total.png">
325 325
326 326 So, chances are good that v8 is making the wrong call by growing the heap total
327 327 here. There is also a good chance I'm still doing something stupid.

0 comments on commit 5ee2f6c

Please sign in to comment.
Something went wrong with that request. Please try again.