26 ms·

Faster than C? Parsing binary data in JavaScript.

219 points by tuxychandru 14y ago

latchkey 14y ago
I really like the style of this writing. Thanks, I learned a bit. I just wish the presenter dug deeper into the final mystery to round out the entire presentation.
PommeDeTerre 14y ago
The excessive use of "fuck" and "shit" throughout the entire article really takes away from its message. It just seems very immature. It's hard for me to take it seriously when it sounds like it was written by an angsty teenager who's trying to look tough in front of his friends, or something like that.
- jlgreco 14y ago
  I would hardly call that excessive profanity. In a 2000+ word article there are what, 10 instances of 'profanity'? Honestly I think it speaks more to your maturity that you would find that so bothering that it could detract from the content of the article.
  - sigzero 14y ago
    Then he and I both lack maturity. So be it. I find the complaint valid.
  - freditup 14y ago
    Honestly, I think it speaks more to your maturity that you are so bothered that people are bothered by profanity. In all seriousness though, profanity is unprofessional. I think a fair definition of profanity is 'vulgar extreme emotion.' If you have to use 'extreme emotion' to get your point across, then you aren't doing it right. You should be able to describe something or explain something with some sort of levelheadedness. On to the 'vulgar' part. We can fairly say that some people could care less about vulgarity and others are bothered by it. So why put it in in the first place? I'm not saying we all have to be ultra politically correct, but if I'm giving a speech on the free market, I'm not going to insert snide comments about liberal politicians and their economic beliefs. I could, it might even make sense in context, but there's no reason to.
    - jlgreco 14y ago
      "profanity is unprofessional" That I can agree with. It is signals more of a casual tone than a professional tone. Why should someone use a casual tone instead of a professional tone? Why not? It is nothing more than individual preference. Write in the style you feel most comfortable with. ("Honestly, I think it speaks more to your maturity that you are so bothered that people are bothered by profanity." That he is bothered is not what makes me think he lacks maturity. That he is bothered to such a degree that he thinks those particular words actually devalue the article itself is what I think signals immaturity. The ability to separate ones emotional response to something from their intellectual appreciation of something is a hallmark of maturity.)
  - PommeDeTerre 14y ago
    I don't take offense to the words that were used. It's more akin to articles that use absurd fonts or blatantly poor color schemes. Such things are unnecessary, and make it more awkward to absorb the actual content. When I see authors doing things that obviously make their work harder to read, it does make me question their judgment, which in turn makes me question the validity of what is being expressed.
    - jlgreco 14y ago
      To be clear, I am not criticizing you for finding certain words to be offensive or thinking that they are offensive words. I am criticizing you for questioning the validity of the article because the author used certain words that you find/think are offensive. I mean seriously...
    - mercurial 14y ago
      I pretty much agree with you, though it certainly depends on the context (I'm more likely to not be bothered by it in a post on a mailing list). But for a technical writeup? You want to be treated like a professional, write like one.
- dmorgan 14y ago
  >The excessive use of "fuck" and "shit" throughout the entire article really takes away from its message. Really? I haven't even noticed it. Only remember reading a great js performance article. Maybe "shit" is in the eye of the beholder? >It just seems very immature. Zzzzzz.
- alphabeta6 14y ago
  Absolutely. What baffles me is in the defense of the use of profanity in this article/talk? Perhaps he had sized up his audience and had determined that those he was talking to could only absorb the message if it were dumbed down a bit?
  - gjm11 14y ago
    "Using profanity" and "dumbed down" have basically nothing to do with one another. I've read very intelligent things with lots of expletives, and incredibly simplistic things with none. Why are you baffled by the fact that some people defend the author's use of profanity? Surely the fact that some people simply aren't bothered by profanity isn't news to you?
- oellegaard 14y ago
  Sorry to say, if the article is good enough, I don't care who wrote it - immature or not. If I could learn something from a 13 year old kid, I would love to. In Europe "fuck" and "shit" are anyway not considered offensive at all (at least in the countries, where English is not the first language).
  - zeroonetwothree 14y ago
    Surely you can imagine the equivalent in your language. Likewise for English speakers using foreign profanities is not considered offensive.
- jh3 14y ago
  Your entitled to your opinion. The author is entitled one as well. What you think about his style of writing does not matter. Expletives are not immature, you just view them as such. Again, that is fine and is your choice. There are (very few) people (in this thread who) agree with your view. There are over 25 comments actually discussing the article instead singling out of individual words to focus on. According to you, since there other people discussing the article and not caring about the sparse use of swear words they too must be immature. Here is my opinion: it is more annoying to see people like you complain about the "excessive" use of "fuck" and "shit" every time an article is posted that contains "fuck," "shit," or something similar.
- pinchyfingers 14y ago
  I didn't even notice the profanity. He's not in a corporate setting or anything, who cares?
mkaufmann 14y ago
For me myself it is often very motivating (sometimes demotivating) if somebody comes up and implements the same thing I want to do - but they accomplish 10x faster performance (even better if it is written in a cleaner style). The author seems also to rather enjoy those challenges ;) In my interpretation the question "Faster than C?" is relevant because it is very easy to think that certain problems (like parsing binary data) are just not a good fit for language Y and thus the performance can't be good. Even if C performance is not attainable sometimes one cat get closer than one would think. My last question is regarding his optmization example.I don't program javascript and thus have difficulties understanding how the optimized variant could every be faster than the original one. String concatenation and evaluation should not be faster (from my laymans perspective) than setting an indexed value to an array? (Ok actually it probably is not an array but a hash map, but are those so inefficient in java script? Or is it rather behaving like a sorted list where every value is inserted via binarcy search?).I would be very happy to get some insight.
- dbaupp 14y ago
  Regarding your last question: the string concatenation/evaluation happens once while creating the parseRow function and from then parseRow is a compiled/JIT'd function object, no string handling happening. The problem with the original is not the hash map creation, but the fact that it requires all sorts of extra loops, and array & property look-ups. Also, I think that is possibly some missing information there, since in the second version the column names are fixed (so the columns argument to parseRow is ignored), while in the first they are not.
  - mkaufmann 14y ago
    Ah ok so this is probably the parser equivalent to precompiled queries. Given a fixed query, a specific parse row function is created once and than reused. Thanks! While I think code generation is certainly the right approach in some examples, I see one problem in this example: As the parser is basically pregenerated using a certain column definition, why does the generated function has an parameter columns? It is simply discarded. So I would say it should rather be: var parseRow = new Function('parser', code);
kghose 14y ago
I write code primarily to analyze data from my experiments, and I do it primarily in Python. I have been told (and have read) repeatedly, that optimizing is to be done right at the end and only to optimize the inner most loop etc. From my reading, this guy is advocating the exact opposte: optimize as you code. It sounds sensible, but what to other people who have to optimize for a living have to say?
- dmorgan 14y ago
  >From my reading, this guy is advocating the exact opposte: optimize as you code. Huh? He had ALREADY written his library before he started optimizing. He even says that the profiler didn't show much, because he had all parsing code inside one big function.
  - icebraining 14y ago
    No, those were just the optimizations he listed, he never said he hadn't optimize before.
    - dmorgan 14y ago
      >he never said he hadn't optimize before. And he never said he _did_ optimize before. Which kinda defeats the complain in the parent comment that he advocates optimize as you program.
      - icebraining 14y ago
        But he does: that's what his "benchmark drive development" is all about. He even starts by benchmarking an empty function!
- simonw 14y ago
  I think the difference here is that the problem is completely understood from the start: there's a MySQL protocol (which the author has already implemented in the past) and his project needs to be able to handle that exact protocol as quickly as possible.
snprbob86 14y ago
I love the "eval is awesome" section. It's taken my years of study, but I finally "get" Lisp. Let me summarize pg's On Lisp: "Lisp is a language for writing programs fast" 1) Write a function 2) Write a function that does something similar to #1 3) Begin to write a function that does something similar to #1 and #2 4) Abstract out the commonalities between #1 through #3 5) Encounter all kinds of new use cases for your abstraction in #4 6) Wait for #5 to become unwieldy 7) Abstract #4 even further, until you have something that resembles an interpreter 8) Wait for #7 to become a performance bottleneck 9) Write a compiler that takes inputs to #7 and turns them into #1 through #5 "Lisp is a language for writing fast programs"
- yairchu 14y ago
  Doesn't it cause a "Javascript eval injection" vulnerability? I don't know Javascript so I may be wrong here, but: * Suppose someone uses this library to create a "MariaSQL Explorer App", where you give the app connection credentials and it connects to the database and shows you the data etc. * A malicious attacker tells a user "have a look at my database" and the user goes to the attacker's database. * The attacker's database (or spoof of one) has a column called 'dummy": MALICIOUS_CODE(), "colname'. notice the '"' chars inside column name. * The MALICIOUS_CODE() runs in the user's node.js app. Perhaps it sends the attacker the passwords to other databases from the app's keychain or something.. * Profit
  - Groxx 14y ago
    Which is why you sanitize input. Which every sql-communicating system must eventually do somewhere - this is no different. Besides, that's just an example snippet.
    - Zr40 14y ago
      If you sanitize input, it implies you're inserting the input into an execution environment. If possible, it's better to treat data as data. In the Javascript eval case, it's definitely possible; just access the data through a variable instead of inserting it into the eval'ed code.
sneak 14y ago
Thousands of words about optimizing the reinvention of a wheel. I thought we were hackers? We use libmysqlclient and stfu because we don't give a shit what language a client library is in because it WORKS and isn't unacceptably slow and LETS US SHIP. I really dislike this whole crowd and attitude.
- Groxx 14y ago
  What point are you trying to make? This kind of crowd and attitude is why you have a client library that works and isn't unacceptably slow and lets you ship.
- LnxPrgr3 14y ago
  Reinventing the wheel is a good thing when what you get is a better wheel, or even just one better suited to your purpose. Ever notice we're not driving cars on ox cart wheels?
  - gruseom 14y ago
    As someone once brilliantly (I thought) put it on HN: has anything ever needed more reinventing than the wheel?
- dmorgan 14y ago
  >Thousands of words about optimizing the reinvention of a wheel. Without the "re-invention of wheel" we would still use stone wheels a la Flintstones or wooden carriage wheels. And without optimizing our wheels we would still have the 1920's version of rubber-made wheels. >I thought we were hackers? We use libmysqlclient and stfu because we don't give a shit what language a client library is in because it WORKS and isn't unacceptably slow and LETS US SHIP. And you "thought you were hackers"? That's not a hacker attitude, that's an enterprise code monkey attitude. I mean, we "use it because it's isn't unacceptably slow and it lets us ship"? WTF. Hacking, in the purest sense, is not even about shipping at ALL. It's about the joy of tinkering and discovering and improving and optimizing. It's not about shipping some stuff to the market with whatever happens to be available, and some "good enough" mentality. >I really dislike this whole crowd and attitude. It's called _Hacker_ News for a reason. Perhaps you were looking for "Building average shit with off the shelve components News". I mean, _complaining about_ and writing that you _dislike_ a guy: 1) creating a free, open source, library useful to many 2)improving upon the status quo in MySQL driver libraries for Node 3) writing about it, to present his results, other's improvements, and useful tidbits he found? It must take a very disturbing sense of reality, entitlement, and self-importance to do it.
Groxx 14y ago
Excellent read. Written well, convincing examples of why it's good advice, and doesn't waste space in making its point.
sil3ntmac 14y ago
Very worthwhile and well-designed writeup! I do wish that he had expanded the last argument to show what/how he fixed the performance problem. Also, does anyone know why eval is faster than just defining the function? I mean wtf, why doesn't v8 make this optimization?
- daeken 14y ago
  He's not just evalling code, but building a function without loops and lots of lookups. That's not something you can generalize.
- mistercow 14y ago
  >Also, does anyone know why eval is faster than just defining the function? I mean wtf, why doesn't v8 make this optimization? There are three optimizations I see in the eval example: 1. The object is created as a literal rather than by property assignment (see http://jsperf.com/object-literals-vs-object-properties http://jsperf.com/object-literals-vs-object-properties). 2. The for loop loop is unrolled. 3. The column names are cached in the function and do not have to be retrieved each time. The reason these can't be done by v8 on its own is that they make assumptions that v8 can't guarantee. For the first two, you have to guarantee that the columns array is always the same length. For the first and last, you have to guarantee that the columns will always have the same names. So even though you take a big hit on the initial eval of the function, you'll likely make up for it by having a better-optimized function.
  - rb12345 14y ago
    I noticed a possible issue with the code generation, which may cause the issues with excessive heap allocation that were reported: var code = 'return {\n'; columns.forEach(function(column) { code += '"' + column.name + '":' + 'parser.readColumnValue(),\n'; }); code += '};\n'; var parseRow = new Function('columns', 'parser', code); Instead of performing so many appends to a single string, I would try using map() and then join() the resulting strings: var code = ['return {\n', columns.map(function(column) { return '"' + column.name + '":' + 'parser.readColumnValue(),\n'; }).join(''), '};\n'].join(''); var parseRow = new Function('columns', 'parser', code); Of course, this depends on how often the parseRow function is created...
masklinn 14y ago
> But, life is never this easy. Your code may not be very profilable. This was the case with my mysql 0.9.6 library. My parser was basically one big function with a huge switch statement. I thought this was a good idea because this is how Ryan's http parser for node looks like and being a user of node, I have a strong track record for joining cargo cults. Anyway, the big switch statement meant that the profiler output was useless for me, "Parser#parse" was all it told me about : (. FWIW this is also a case of "get better tools". Line profilers exist, and they can handle that kind of cases (though the instrumentation costs go up likewise).
- netghost 14y ago
  For Node and V8? I'm sure you're right, but when I was poking around I didn't see much more than suggestions to use "node --prof". Which tools have you found useful?
  - masklinn 14y ago
    > For Node and V8? I don't know, I use neither. I'm just saying, there are profiling tools which handle the "One Big Function" pattern.
willvarfar 14y ago
I think that the drivers can do a lot more to improve DB performance. http://williamedwardscoder.tumblr.com/post/16516763725/how-i-got-massively-faster-db-with-async-batching http://williamedwardscoder.tumblr.com/post/16516763725/how-i... At low load, the DB worker is idle when a request arrives and it can be dispatched immediately. But under load, the DB worker is busy when requests arrive and they build up as a backlog. When a backlog builds, the DB worker can examine the pending requests and combine those that it can to reduce the total number of requests. Not all requests are combinable and there can be subtle rules and side-effects. It is likely that a driver with just a modicum of combining ability would be very conservative e.g. simply combining single-key selects that are queued adjacently or such. Even still, the gains can be massive and performance never worse. (Oh, equally applicable to NoSQL too.)
tabbyjabby 14y ago
I am extremely doubtful that optimized C is going to be equally performant as optimized JavaScript. There is innate overhead when using an interpreted language, no matter how advanced the interpreter. JavaScript is also garbage collected, while C is not, adding an additional level of overhead. At no point in this article are we shown the code of this new parser. We are also told that is incomplete. So we have a parser which we can't see and which is not finished, but apparently dominates its C counterpart in performance. This leads to me to believe one of two things: 1. The parser isn't complete, and its unimplemented functionality is going to be more expensive in terms of performance than the author anticipated, thus rendering his preliminary results void. 2. The implementation of the C extension he is comparing against is not very well optimized. As said above, I find it very hard to believe that well optimized C is going to be beaten by well optimized JavaScript.
- Jare 14y ago
  From the article: > JavaScript will no longer be the bottleneck. At this point the main cost is turning network data into JavaScript objects. This cost is equal for JavaScript libraries, as well as for C++ addons making V8 calls. Also, when a single client can process 5000 MBit/s utilizing a single CPU, your MySQL server has long exploded Remember these are Node drivers, so everything has to end up becoming a JS object.
- eric_bullington 14y ago
  Is that a blanket statement about C versus any dynamic language, or just JavaScript? Because with LuaJIT2, Mike Pall has already shown that a highly-optimized Lua interpreter can hold its own against optimized C, and sometimes even surpass it. Here's a nice look at some of the magic he does in assembler to get LuaJIT at such a high level of performance: http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://article.gmane.org/gmane.comp.lang.lua.general/75426 My point is, there's nothing inherently unbeatable about C. I think that a select group of dynamic language -- probably including JavaScript -- can and will reach that level of performance, or at least close to it. They just haven't been around as long.
  - 14y ago
eric_bullington 14y ago
This is an outstanding overview of how to build fast programs in JavaScript. I really appreciate the fact that Felix took the time to write it. I learned a lot, and will definitely integrate this into my work whenever performance-critical code is involved. Particularly since I enjoy dataviz so much. I'm a little surprised that someone so into JavaScript is using R and ggplot2 to visualize his data, and not d3 along with CoffeeScript for munging data (or Python if you can't stand CoffeeScript). Don't get me wrong, R is a powerful tool, but with d3 you can skip the whole ImageMagick/Skitch step since you're making visualizations directly for the web. Plus, once you've grasped d3's declarative approach (took me a while), it's so easy to quickly make powerful visualizations with it. In fact, it was partially inspired by ggplot2, if I'm not mistaken. And to quickly munge/clean data, I've found CoffeeScript does very well here, similar to how easy it is to use Python for this task. I wouldn't want to write out JavaScript when rapidly trying to get data in the right format for visualizations, but with CoffeeScript and a functionally-oriented library like underscore, it's pretty easy. That said, I'm sure once you've mastered such an intricate tool as R, it's hard to give up that power. But if you're a node devotee and you're looking for a good tool in JavaScript to visualize data, you can't get much better than d3. I know a lot of dataviz folks are learning JavaScript just so they can have access to d3.
- rgbrgb 14y ago
  Really the nice thing about ggplot2 is that each of those figures were probably like 1 line of code. Having a DSL designed for your data analysis is awesome.
- Myrmornis 14y ago
  I like d3 (and coffeescript). But... df <- read.delim("benchmark.tsv") boxplot(df$timing ~ df$implementation) Versus...hmm. How many hours / LOC would that take you in d3 and coffeescript? It will be great when it happens (nvd3 looks promising) but I don't think d3 is an exploratory data analysis tool yet.
tantalor 14y ago
My only problem with this article was that it didn't once mention parsing binary data, except in the title.
goggles99 14y ago
Um every fast and decent JS engine IS WRITTEN IN C!!! I refuse to click on anything as ridiculous sounding as "Faster than C? Parsing binary data in JavaScript". JavaScript will NEVER be faster than C. If you personally test it and it is - all that you have really proven is that the C compiler you are using was horribly written and is probably 20+ years old. The level of ignorance that programmers have about low level languages and the performance cost of abstractions amazes me sometimes.
- tptacek 14y ago
  This is a very silly point of view. What you think you're arguing is that Javascript can't conceivably be faster than native code, and you're conflating C with native code. But C isn't machine code either; like Javascript, it's transformed into machine code by a compiler. I don't generally think that Javascript runtimes are going to routinely beat C compilers for most performant execution of basic programs any time soon, but I'd happily bet that some high level language JIT is going to give C a real run for its money sometime soon. That JIT will inevitably be expressible in C, but when your recourse as a C programmer is "implement the important parts of the JIT for language X, then proceed to solve your real problem", you're not making much of a case for C.
  - goggles99 14y ago
    I am not even close to conflating C with native code (although it is the lowest level language next to Assembly). C is the lowest level structured language and JS is among the highest. The fact that they are both ultimately compiled to a processor level binary means very little. Since it seems so simple and plausible that a high level JITted language can be on par with C, why did you not explain how? You cannot because you clearly don't understand language compilation and the laws that exist between performance and abstractions - so I am confused by your argument. Let me put it simply, take any two languages - both ultimately compile to machine code, one has the overhead of bounds checking, run-time type resolution and garbage collection (there is actually much more that I could mention but for brevity...) and the other does not. Now please explain to me how the one WITH all this overhead could possibly be faster? There is only one way - If the C compiler were egregiously under-optimized. This will be the case till the end of time. All other things being equal, the executable code with more overhead to slow it down will lose. This seems a very simple concept to me - I cannot understand how it is so hard to grasp. Perhaps it is because along side learning Java, HTML and JavaScript - I also learned Assembly Language, C, C++ and hardware architectures.
overbroad 14y ago
"Faster than C" seems to imply that the author is not seeing the true value of C. It is more than just speed. You can only build so much with Javascript. With C, the possibilities are limitless. For a specific task like parsing, use whatever language you want. But please do not believe that by knowing Javascript you can both dismiss C as an optimal language and that you can build anything. You can't, as to either. As it stands, by relying on Javsacsript you're restricted to a browser or Node.js and whoever controls the browser and Node.js effectively has final control over your opportunitities. What's the browser written in? Javascript? What is Node.js written in? Who cares if your parser is faster than C? If it's "fast enough", that's all that matters. Users of big, complex, graphical browsers or mySQL databases are well accustomed to slow speeds. They have learned how to wait.
- icebraining 14y ago
  Technically, you can write anything in JavaScript, for the simple reason you can manipulate bytes arbitrarily (using Typed Arrays), and platforms like NodeJS and Rhino let you write those bytes to a file and execute it, so you could (in theory) write a x86 compiler in JavaScript and run the result without ever dropping to C. As an existing example, PyPy -a Python JIT compilter- is itself written in a subset of Python. In the browser case, it's true that your JavaScript is restricted, but C is even more restricted: it doesn't run at all! (NaCl excluded)
  - overbroad 14y ago
    Does Javascript run outside the browser and outside of a platform like Node.js? I want stuff that can run on bare metal as well as on top of other code (software platform). Personally, I don't care about browsers. One application of a gazillion possible applications. They are an afterthought. I care about sockets and the ability to connect a machine to other machines over a network. I care about code that can boot a computer, code that can be used to write drivers to control hardware (maybe some new hardware that just hits the market), and code that let's us build on top of that. With this code we should be able to build a kernel and userspace utilities and thereby manage to operate the hardware. Once everything is up and running, then we can install any scripting language we want. We don't have to use the same language we used to build the system to do any work after that, but we could. Indeed many higher level things are written in C, e.g., the interpreters for languages like JavaScript and the web browsers they are a part of. Maybe there's a reason for that? If the best code for building from the ground up on any given piece of hardware is Javascript, it's news to me. Any examples? I have a new piece of hardware. Can I boot it using JavaScript? Can I control the hardware with JavaScript? I believe the OP just wanted to do parsing in userspace. Personally I use C for that (generated from flex), but there are countless languages that can do parsing. Why he chose to attack C I have no idea. Like I said, once the computer is up and running (thanks to C), we can use any language we like. We can run "web browsers", and software platforms. And JavaScript. So, have fun with your JavaScript. But I'm pretty sure C isn't going away anytime soon.
philhippus 14y ago
An equivalent claim: Faster than Assembly? Parsing binary data in JavaScript. Pah.
andoriyu 14y ago
And not a single word about DTrace?
pmiller2 14y ago
I'll just leave this here: http://c2.com/cgi/wiki?FasterThanCee http://c2.com/cgi/wiki?FasterThanCee
goggles99 14y ago
Please stop with the X higher level language can be faster than C unless you can challenge the limitations imposed by the laws of physics. Not which compiler is better. I can always find a better or worse C or JS compiler/JITter so that proves nothing. Doing more (Which all more highly abstracted languages currently do) in less time with all else being the same is not possible as we understand quantum physics today. This title is clearly linkbait...
- rat87 14y ago
  > Please stop with the X higher level language can be faster than C unless you can challenge the limitations imposed by the laws of physics. Not which compiler is better. I can always find a better or worse C or JS compiler/JITter so that proves nothing. Turing equivalence and not even turing equivalence but 2 pieces of code with roughly the same functionality does not dictate the speed between them. You seem to be under some sort of misconception that two pieces of code have to be implemented in the same. For a long time tcl led the computer language shootout regex test because it has a wicked fast regex library(written in c I think). Nowadays the c version of that test uses the tcl regex library and is beaten by v8(chrome) javascript's even faster regex library(written in c++). It is hard to beat c in speed and it is rare when something implemented in a different language does it. When it does it is frequently do to the algorithm/way it was implemented. The reason that this is so is that few people care enough about beating c with c++ being the only real contender. if you are careful you can beat c code with c++(almost all c++'s slower features do not slow it down if not used) add that to some cool compile time tricks with template metahackery and c++'s better inlining and you can do it. The other part about beating c is complexity. Certain things are complex to implement in c. There is a reason we use so little assembly anymore, it's possible for smart people to beat optimizing compilers for certain cases but the general case isn't so pretty for it. Also with the rise of more/cheaper memory for gc to work well(and when it does it goes like hell on wheels) and parallel computers(parallelism being much easier in some languages then c) we may see it more soon. People have been saying that for a while but still.
  - goggles99 14y ago
    >Turing equivalence and not even turing equivalence but 2 pieces of code with roughly the same functionality does not dictate the speed between them. You seem to be under some sort of misconception that two pieces of code have to be implemented in the same I am merely pointing out that there is overhead with every VM. This is especially true with every current JITted JavaScript in use today (more so than with the JVM and CLR). So how could it possibly be faster if both implementations use an equal amount of optimization otherwise. How is this even ever an argument?
afhof 14y ago
Why does everyone keep saying Doing X in Language Y is faster than X in Language Z? Really they are comparing compilers, not languages. Everyone seems to just keep making potshots at Language Z.
camus 14y ago
INFLAMMATORY headline for self-branding and publicity , doesnt go much further. Yes javascript can be fast but in the end , having to write evals to gain performances demonstrate that there is something really wrong with that langage...
- ben0x539 14y ago
  I disagree!! Being able to use evals to dynamically generate code for unrolled loops (and other similarly specialized procedures) sounds like a pretty amazing tool, and I can't not consider having it readily available an advantage of Javascript compared to C.
username_taken 14y ago
This is only part of the picture. This version of the driver is much slower than the driver based on libmysqclient. See the benchmarks at the bottom. It's a more real world test combining both reads and writes. https://github.com/mgutz/mapper https://github.com/mgutz/mapper
agentultra 14y ago
I guess the hope of high-level languages is that you can build a more interesting vocabulary from complex concepts. http://www.pvk.ca/Blog/2012/08/27/tabasco-sort-super-optimal-merge-sort/ http://www.pvk.ca/Blog/2012/08/27/tabasco-sort-super-optimal... It seems that there's a lot of effort going into making languages, "faster than C." Perhaps we would all be better off working with languages that just give us better abstractions -- user vocabularies. Layers on layers. Don't get me wrong, C is the right language and a good tool for many situations. It's just that if you're going to extend the vocabulary then why do you have to change the implementation? If you want to optimize why optimize the compiler at such a low level? Either way I just want to say that it's an interesting conversation and I'm looking forward to seeing more.
chmike 14y ago
Check the code : https://github.com/felixge/node-mysql https://github.com/felixge/node-mysql Note: it uses node_buffer.cc which is some C++ code in node. So it is not exactly pure Javascript.
faragon 14y ago
No way. Even with equal-efficient code, there is an additional point that is often ignored: Data structures are way more simple in C, with less overhead, and with higher cache-hit ratio, because more data fits in CPU data cache. As example, gcj is as fast as g++ for code generation (both generating machine code, without virtual machine involved), however, in benchmarking appears to be slower, just because the data structures. If you tweak the Java code for use simpler data structures, e.g. integer or byte arrays, data overhead gets reduced, so memory cache hit increases, thus keeping similar performance to C/C++. Other cases, like Java bytecode running on a VM, even with great JIT like HotSpot, suffers also a lot because of data structures, so even when generated code is quite decent (runtime profiling, etc.), penalty is there, so code will suffer great penalty unless running with huge L3 cache (e.g. 32-48MB), being noticeable anyway no matter how much cache you add when having to do many memory indirections more. And of course, when comparing, you have to compare equivalent things, e.g. Java <-> C/C++ ports, and not completely different software with different implementation (e.g. optimized built-in string handling vs non-optimized C string handling -e.g. ASCIIz string handling is slow, because of stupid C string function implementation, not because the C language itself, being the reason of C strings not being used for high performance code, even when writting in C-).

219 points by tuxychandru 14y ago

I really like the style of this writing. Thanks, I learned a bit. I just wish the presenter dug deeper into the final mystery to round out the entire presentation.

PommeDeTerre 14y ago

The excessive use of "fuck" and "shit" throughout the entire article really takes away from its message. It just seems very immature. It's hard for me to take it seriously when it sounds like it was written by an angsty teenager who's trying to look tough in front of his friends, or something like that.

jlgreco 14y ago
I would hardly call that excessive profanity. In a 2000+ word article there are what, 10 instances of 'profanity'? Honestly I think it speaks more to your maturity that you would find that so bothering that it could detract from the content of the article.
- sigzero 14y ago
  Then he and I both lack maturity. So be it. I find the complaint valid.
- freditup 14y ago
  Honestly, I think it speaks more to your maturity that you are so bothered that people are bothered by profanity. In all seriousness though, profanity is unprofessional. I think a fair definition of profanity is 'vulgar extreme emotion.' If you have to use 'extreme emotion' to get your point across, then you aren't doing it right. You should be able to describe something or explain something with some sort of levelheadedness. On to the 'vulgar' part. We can fairly say that some people could care less about vulgarity and others are bothered by it. So why put it in in the first place? I'm not saying we all have to be ultra politically correct, but if I'm giving a speech on the free market, I'm not going to insert snide comments about liberal politicians and their economic beliefs. I could, it might even make sense in context, but there's no reason to.
  - jlgreco 14y ago
    "profanity is unprofessional" That I can agree with. It is signals more of a casual tone than a professional tone. Why should someone use a casual tone instead of a professional tone? Why not? It is nothing more than individual preference. Write in the style you feel most comfortable with. ("Honestly, I think it speaks more to your maturity that you are so bothered that people are bothered by profanity." That he is bothered is not what makes me think he lacks maturity. That he is bothered to such a degree that he thinks those particular words actually devalue the article itself is what I think signals immaturity. The ability to separate ones emotional response to something from their intellectual appreciation of something is a hallmark of maturity.)
- PommeDeTerre 14y ago
  I don't take offense to the words that were used. It's more akin to articles that use absurd fonts or blatantly poor color schemes. Such things are unnecessary, and make it more awkward to absorb the actual content. When I see authors doing things that obviously make their work harder to read, it does make me question their judgment, which in turn makes me question the validity of what is being expressed.
  - jlgreco 14y ago
    To be clear, I am not criticizing you for finding certain words to be offensive or thinking that they are offensive words. I am criticizing you for questioning the validity of the article because the author used certain words that you find/think are offensive. I mean seriously...
  - mercurial 14y ago
    I pretty much agree with you, though it certainly depends on the context (I'm more likely to not be bothered by it in a post on a mailing list). But for a technical writeup? You want to be treated like a professional, write like one.
dmorgan 14y ago
>The excessive use of "fuck" and "shit" throughout the entire article really takes away from its message. Really? I haven't even noticed it. Only remember reading a great js performance article. Maybe "shit" is in the eye of the beholder? >It just seems very immature. Zzzzzz.
alphabeta6 14y ago
Absolutely. What baffles me is in the defense of the use of profanity in this article/talk? Perhaps he had sized up his audience and had determined that those he was talking to could only absorb the message if it were dumbed down a bit?
- gjm11 14y ago
  "Using profanity" and "dumbed down" have basically nothing to do with one another. I've read very intelligent things with lots of expletives, and incredibly simplistic things with none. Why are you baffled by the fact that some people defend the author's use of profanity? Surely the fact that some people simply aren't bothered by profanity isn't news to you?
oellegaard 14y ago
Sorry to say, if the article is good enough, I don't care who wrote it - immature or not. If I could learn something from a 13 year old kid, I would love to. In Europe "fuck" and "shit" are anyway not considered offensive at all (at least in the countries, where English is not the first language).
- zeroonetwothree 14y ago
  Surely you can imagine the equivalent in your language. Likewise for English speakers using foreign profanities is not considered offensive.
jh3 14y ago
Your entitled to your opinion. The author is entitled one as well. What you think about his style of writing does not matter. Expletives are not immature, you just view them as such. Again, that is fine and is your choice. There are (very few) people (in this thread who) agree with your view. There are over 25 comments actually discussing the article instead singling out of individual words to focus on. According to you, since there other people discussing the article and not caring about the sparse use of swear words they too must be immature. Here is my opinion: it is more annoying to see people like you complain about the "excessive" use of "fuck" and "shit" every time an article is posted that contains "fuck," "shit," or something similar.
pinchyfingers 14y ago
I didn't even notice the profanity. He's not in a corporate setting or anything, who cares?

mkaufmann 14y ago

For me myself it is often very motivating (sometimes demotivating) if somebody comes up and implements the same thing I want to do - but they accomplish 10x faster performance (even better if it is written in a cleaner style). The author seems also to rather enjoy those challenges ;) In my interpretation the question "Faster than C?" is relevant because it is very easy to think that certain problems (like parsing binary data) are just not a good fit for language Y and thus the performance can't be good. Even if C performance is not attainable sometimes one cat get closer than one would think. My last question is regarding his optmization example.I don't program javascript and thus have difficulties understanding how the optimized variant could every be faster than the original one. String concatenation and evaluation should not be faster (from my laymans perspective) than setting an indexed value to an array? (Ok actually it probably is not an array but a hash map, but are those so inefficient in java script? Or is it rather behaving like a sorted list where every value is inserted via binarcy search?).I would be very happy to get some insight.

dbaupp 14y ago
Regarding your last question: the string concatenation/evaluation happens once while creating the parseRow function and from then parseRow is a compiled/JIT'd function object, no string handling happening. The problem with the original is not the hash map creation, but the fact that it requires all sorts of extra loops, and array & property look-ups. Also, I think that is possibly some missing information there, since in the second version the column names are fixed (so the columns argument to parseRow is ignored), while in the first they are not.
- mkaufmann 14y ago
  Ah ok so this is probably the parser equivalent to precompiled queries. Given a fixed query, a specific parse row function is created once and than reused. Thanks! While I think code generation is certainly the right approach in some examples, I see one problem in this example: As the parser is basically pregenerated using a certain column definition, why does the generated function has an parameter columns? It is simply discarded. So I would say it should rather be: var parseRow = new Function('parser', code);

kghose 14y ago

I write code primarily to analyze data from my experiments, and I do it primarily in Python. I have been told (and have read) repeatedly, that optimizing is to be done right at the end and only to optimize the inner most loop etc. From my reading, this guy is advocating the exact opposte: optimize as you code. It sounds sensible, but what to other people who have to optimize for a living have to say?

dmorgan 14y ago
>From my reading, this guy is advocating the exact opposte: optimize as you code. Huh? He had ALREADY written his library before he started optimizing. He even says that the profiler didn't show much, because he had all parsing code inside one big function.
- icebraining 14y ago
  No, those were just the optimizations he listed, he never said he hadn't optimize before.
  - dmorgan 14y ago
    >he never said he hadn't optimize before. And he never said he _did_ optimize before. Which kinda defeats the complain in the parent comment that he advocates optimize as you program.
    - icebraining 14y ago
      But he does: that's what his "benchmark drive development" is all about. He even starts by benchmarking an empty function!
simonw 14y ago
I think the difference here is that the problem is completely understood from the start: there's a MySQL protocol (which the author has already implemented in the past) and his project needs to be able to handle that exact protocol as quickly as possible.

snprbob86 14y ago

I love the "eval is awesome" section. It's taken my years of study, but I finally "get" Lisp. Let me summarize pg's On Lisp: "Lisp is a language for writing programs fast" 1) Write a function 2) Write a function that does something similar to #1 3) Begin to write a function that does something similar to #1 and #2 4) Abstract out the commonalities between #1 through #3 5) Encounter all kinds of new use cases for your abstraction in #4 6) Wait for #5 to become unwieldy 7) Abstract #4 even further, until you have something that resembles an interpreter 8) Wait for #7 to become a performance bottleneck 9) Write a compiler that takes inputs to #7 and turns them into #1 through #5 "Lisp is a language for writing fast programs"

yairchu 14y ago
Doesn't it cause a "Javascript eval injection" vulnerability? I don't know Javascript so I may be wrong here, but: * Suppose someone uses this library to create a "MariaSQL Explorer App", where you give the app connection credentials and it connects to the database and shows you the data etc. * A malicious attacker tells a user "have a look at my database" and the user goes to the attacker's database. * The attacker's database (or spoof of one) has a column called 'dummy": MALICIOUS_CODE(), "colname'. notice the '"' chars inside column name. * The MALICIOUS_CODE() runs in the user's node.js app. Perhaps it sends the attacker the passwords to other databases from the app's keychain or something.. * Profit
- Groxx 14y ago
  Which is why you sanitize input. Which every sql-communicating system must eventually do somewhere - this is no different. Besides, that's just an example snippet.
  - Zr40 14y ago
    If you sanitize input, it implies you're inserting the input into an execution environment. If possible, it's better to treat data as data. In the Javascript eval case, it's definitely possible; just access the data through a variable instead of inserting it into the eval'ed code.

sneak 14y ago

Thousands of words about optimizing the reinvention of a wheel. I thought we were hackers? We use libmysqlclient and stfu because we don't give a shit what language a client library is in because it WORKS and isn't unacceptably slow and LETS US SHIP. I really dislike this whole crowd and attitude.

Groxx 14y ago
What point are you trying to make? This kind of crowd and attitude is why you have a client library that works and isn't unacceptably slow and lets you ship.
LnxPrgr3 14y ago
Reinventing the wheel is a good thing when what you get is a better wheel, or even just one better suited to your purpose. Ever notice we're not driving cars on ox cart wheels?
- gruseom 14y ago
  As someone once brilliantly (I thought) put it on HN: has anything ever needed more reinventing than the wheel?
dmorgan 14y ago
>Thousands of words about optimizing the reinvention of a wheel. Without the "re-invention of wheel" we would still use stone wheels a la Flintstones or wooden carriage wheels. And without optimizing our wheels we would still have the 1920's version of rubber-made wheels. >I thought we were hackers? We use libmysqlclient and stfu because we don't give a shit what language a client library is in because it WORKS and isn't unacceptably slow and LETS US SHIP. And you "thought you were hackers"? That's not a hacker attitude, that's an enterprise code monkey attitude. I mean, we "use it because it's isn't unacceptably slow and it lets us ship"? WTF. Hacking, in the purest sense, is not even about shipping at ALL. It's about the joy of tinkering and discovering and improving and optimizing. It's not about shipping some stuff to the market with whatever happens to be available, and some "good enough" mentality. >I really dislike this whole crowd and attitude. It's called _Hacker_ News for a reason. Perhaps you were looking for "Building average shit with off the shelve components News". I mean, _complaining about_ and writing that you _dislike_ a guy: 1) creating a free, open source, library useful to many 2)improving upon the status quo in MySQL driver libraries for Node 3) writing about it, to present his results, other's improvements, and useful tidbits he found? It must take a very disturbing sense of reality, entitlement, and self-importance to do it.

Groxx 14y ago

Excellent read. Written well, convincing examples of why it's good advice, and doesn't waste space in making its point.

sil3ntmac 14y ago

Very worthwhile and well-designed writeup! I do wish that he had expanded the last argument to show what/how he fixed the performance problem. Also, does anyone know why eval is faster than just defining the function? I mean wtf, why doesn't v8 make this optimization?

daeken 14y ago
He's not just evalling code, but building a function without loops and lots of lookups. That's not something you can generalize.
mistercow 14y ago
>Also, does anyone know why eval is faster than just defining the function? I mean wtf, why doesn't v8 make this optimization? There are three optimizations I see in the eval example: 1. The object is created as a literal rather than by property assignment (see http://jsperf.com/object-literals-vs-object-properties http://jsperf.com/object-literals-vs-object-properties). 2. The for loop loop is unrolled. 3. The column names are cached in the function and do not have to be retrieved each time. The reason these can't be done by v8 on its own is that they make assumptions that v8 can't guarantee. For the first two, you have to guarantee that the columns array is always the same length. For the first and last, you have to guarantee that the columns will always have the same names. So even though you take a big hit on the initial eval of the function, you'll likely make up for it by having a better-optimized function.
- rb12345 14y ago
  I noticed a possible issue with the code generation, which may cause the issues with excessive heap allocation that were reported: var code = 'return {\n'; columns.forEach(function(column) { code += '"' + column.name + '":' + 'parser.readColumnValue(),\n'; }); code += '};\n'; var parseRow = new Function('columns', 'parser', code); Instead of performing so many appends to a single string, I would try using map() and then join() the resulting strings: var code = ['return {\n', columns.map(function(column) { return '"' + column.name + '":' + 'parser.readColumnValue(),\n'; }).join(''), '};\n'].join(''); var parseRow = new Function('columns', 'parser', code); Of course, this depends on how often the parseRow function is created...

masklinn 14y ago

> But, life is never this easy. Your code may not be very profilable. This was the case with my mysql 0.9.6 library. My parser was basically one big function with a huge switch statement. I thought this was a good idea because this is how Ryan's http parser for node looks like and being a user of node, I have a strong track record for joining cargo cults. Anyway, the big switch statement meant that the profiler output was useless for me, "Parser#parse" was all it told me about : (. FWIW this is also a case of "get better tools". Line profilers exist, and they can handle that kind of cases (though the instrumentation costs go up likewise).

netghost 14y ago
For Node and V8? I'm sure you're right, but when I was poking around I didn't see much more than suggestions to use "node --prof". Which tools have you found useful?
- masklinn 14y ago
  > For Node and V8? I don't know, I use neither. I'm just saying, there are profiling tools which handle the "One Big Function" pattern.

willvarfar 14y ago

I think that the drivers can do a lot more to improve DB performance. http://williamedwardscoder.tumblr.com/post/16516763725/how-i-got-massively-faster-db-with-async-batching http://williamedwardscoder.tumblr.com/post/16516763725/how-i... At low load, the DB worker is idle when a request arrives and it can be dispatched immediately. But under load, the DB worker is busy when requests arrive and they build up as a backlog. When a backlog builds, the DB worker can examine the pending requests and combine those that it can to reduce the total number of requests. Not all requests are combinable and there can be subtle rules and side-effects. It is likely that a driver with just a modicum of combining ability would be very conservative e.g. simply combining single-key selects that are queued adjacently or such. Even still, the gains can be massive and performance never worse. (Oh, equally applicable to NoSQL too.)

tabbyjabby 14y ago

I am extremely doubtful that optimized C is going to be equally performant as optimized JavaScript. There is innate overhead when using an interpreted language, no matter how advanced the interpreter. JavaScript is also garbage collected, while C is not, adding an additional level of overhead. At no point in this article are we shown the code of this new parser. We are also told that is incomplete. So we have a parser which we can't see and which is not finished, but apparently dominates its C counterpart in performance. This leads to me to believe one of two things: 1. The parser isn't complete, and its unimplemented functionality is going to be more expensive in terms of performance than the author anticipated, thus rendering his preliminary results void. 2. The implementation of the C extension he is comparing against is not very well optimized. As said above, I find it very hard to believe that well optimized C is going to be beaten by well optimized JavaScript.

Jare 14y ago
From the article: > JavaScript will no longer be the bottleneck. At this point the main cost is turning network data into JavaScript objects. This cost is equal for JavaScript libraries, as well as for C++ addons making V8 calls. Also, when a single client can process 5000 MBit/s utilizing a single CPU, your MySQL server has long exploded Remember these are Node drivers, so everything has to end up becoming a JS object.
eric_bullington 14y ago
Is that a blanket statement about C versus any dynamic language, or just JavaScript? Because with LuaJIT2, Mike Pall has already shown that a highly-optimized Lua interpreter can hold its own against optimized C, and sometimes even surpass it. Here's a nice look at some of the magic he does in assembler to get LuaJIT at such a high level of performance: http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://article.gmane.org/gmane.comp.lang.lua.general/75426 My point is, there's nothing inherently unbeatable about C. I think that a select group of dynamic language -- probably including JavaScript -- can and will reach that level of performance, or at least close to it. They just haven't been around as long.
- 14y ago

eric_bullington 14y ago

This is an outstanding overview of how to build fast programs in JavaScript. I really appreciate the fact that Felix took the time to write it. I learned a lot, and will definitely integrate this into my work whenever performance-critical code is involved. Particularly since I enjoy dataviz so much. I'm a little surprised that someone so into JavaScript is using R and ggplot2 to visualize his data, and not d3 along with CoffeeScript for munging data (or Python if you can't stand CoffeeScript). Don't get me wrong, R is a powerful tool, but with d3 you can skip the whole ImageMagick/Skitch step since you're making visualizations directly for the web. Plus, once you've grasped d3's declarative approach (took me a while), it's so easy to quickly make powerful visualizations with it. In fact, it was partially inspired by ggplot2, if I'm not mistaken. And to quickly munge/clean data, I've found CoffeeScript does very well here, similar to how easy it is to use Python for this task. I wouldn't want to write out JavaScript when rapidly trying to get data in the right format for visualizations, but with CoffeeScript and a functionally-oriented library like underscore, it's pretty easy. That said, I'm sure once you've mastered such an intricate tool as R, it's hard to give up that power. But if you're a node devotee and you're looking for a good tool in JavaScript to visualize data, you can't get much better than d3. I know a lot of dataviz folks are learning JavaScript just so they can have access to d3.

rgbrgb 14y ago
Really the nice thing about ggplot2 is that each of those figures were probably like 1 line of code. Having a DSL designed for your data analysis is awesome.
Myrmornis 14y ago
I like d3 (and coffeescript). But... df <- read.delim("benchmark.tsv") boxplot(df$timing ~ df$implementation) Versus...hmm. How many hours / LOC would that take you in d3 and coffeescript? It will be great when it happens (nvd3 looks promising) but I don't think d3 is an exploratory data analysis tool yet.

tantalor 14y ago

My only problem with this article was that it didn't once mention parsing binary data, except in the title.

goggles99 14y ago

Um every fast and decent JS engine IS WRITTEN IN C!!! I refuse to click on anything as ridiculous sounding as "Faster than C? Parsing binary data in JavaScript". JavaScript will NEVER be faster than C. If you personally test it and it is - all that you have really proven is that the C compiler you are using was horribly written and is probably 20+ years old. The level of ignorance that programmers have about low level languages and the performance cost of abstractions amazes me sometimes.

tptacek 14y ago
This is a very silly point of view. What you think you're arguing is that Javascript can't conceivably be faster than native code, and you're conflating C with native code. But C isn't machine code either; like Javascript, it's transformed into machine code by a compiler. I don't generally think that Javascript runtimes are going to routinely beat C compilers for most performant execution of basic programs any time soon, but I'd happily bet that some high level language JIT is going to give C a real run for its money sometime soon. That JIT will inevitably be expressible in C, but when your recourse as a C programmer is "implement the important parts of the JIT for language X, then proceed to solve your real problem", you're not making much of a case for C.
- goggles99 14y ago
  I am not even close to conflating C with native code (although it is the lowest level language next to Assembly). C is the lowest level structured language and JS is among the highest. The fact that they are both ultimately compiled to a processor level binary means very little. Since it seems so simple and plausible that a high level JITted language can be on par with C, why did you not explain how? You cannot because you clearly don't understand language compilation and the laws that exist between performance and abstractions - so I am confused by your argument. Let me put it simply, take any two languages - both ultimately compile to machine code, one has the overhead of bounds checking, run-time type resolution and garbage collection (there is actually much more that I could mention but for brevity...) and the other does not. Now please explain to me how the one WITH all this overhead could possibly be faster? There is only one way - If the C compiler were egregiously under-optimized. This will be the case till the end of time. All other things being equal, the executable code with more overhead to slow it down will lose. This seems a very simple concept to me - I cannot understand how it is so hard to grasp. Perhaps it is because along side learning Java, HTML and JavaScript - I also learned Assembly Language, C, C++ and hardware architectures.

overbroad 14y ago

"Faster than C" seems to imply that the author is not seeing the true value of C. It is more than just speed. You can only build so much with Javascript. With C, the possibilities are limitless. For a specific task like parsing, use whatever language you want. But please do not believe that by knowing Javascript you can both dismiss C as an optimal language and that you can build anything. You can't, as to either. As it stands, by relying on Javsacsript you're restricted to a browser or Node.js and whoever controls the browser and Node.js effectively has final control over your opportunitities. What's the browser written in? Javascript? What is Node.js written in? Who cares if your parser is faster than C? If it's "fast enough", that's all that matters. Users of big, complex, graphical browsers or mySQL databases are well accustomed to slow speeds. They have learned how to wait.

icebraining 14y ago
Technically, you can write anything in JavaScript, for the simple reason you can manipulate bytes arbitrarily (using Typed Arrays), and platforms like NodeJS and Rhino let you write those bytes to a file and execute it, so you could (in theory) write a x86 compiler in JavaScript and run the result without ever dropping to C. As an existing example, PyPy -a Python JIT compilter- is itself written in a subset of Python. In the browser case, it's true that your JavaScript is restricted, but C is even more restricted: it doesn't run at all! (NaCl excluded)
- overbroad 14y ago
  Does Javascript run outside the browser and outside of a platform like Node.js? I want stuff that can run on bare metal as well as on top of other code (software platform). Personally, I don't care about browsers. One application of a gazillion possible applications. They are an afterthought. I care about sockets and the ability to connect a machine to other machines over a network. I care about code that can boot a computer, code that can be used to write drivers to control hardware (maybe some new hardware that just hits the market), and code that let's us build on top of that. With this code we should be able to build a kernel and userspace utilities and thereby manage to operate the hardware. Once everything is up and running, then we can install any scripting language we want. We don't have to use the same language we used to build the system to do any work after that, but we could. Indeed many higher level things are written in C, e.g., the interpreters for languages like JavaScript and the web browsers they are a part of. Maybe there's a reason for that? If the best code for building from the ground up on any given piece of hardware is Javascript, it's news to me. Any examples? I have a new piece of hardware. Can I boot it using JavaScript? Can I control the hardware with JavaScript? I believe the OP just wanted to do parsing in userspace. Personally I use C for that (generated from flex), but there are countless languages that can do parsing. Why he chose to attack C I have no idea. Like I said, once the computer is up and running (thanks to C), we can use any language we like. We can run "web browsers", and software platforms. And JavaScript. So, have fun with your JavaScript. But I'm pretty sure C isn't going away anytime soon.

philhippus 14y ago

An equivalent claim: Faster than Assembly? Parsing binary data in JavaScript. Pah.

andoriyu 14y ago

And not a single word about DTrace?

pmiller2 14y ago

I'll just leave this here: http://c2.com/cgi/wiki?FasterThanCee http://c2.com/cgi/wiki?FasterThanCee

goggles99 14y ago

Please stop with the X higher level language can be faster than C unless you can challenge the limitations imposed by the laws of physics. Not which compiler is better. I can always find a better or worse C or JS compiler/JITter so that proves nothing. Doing more (Which all more highly abstracted languages currently do) in less time with all else being the same is not possible as we understand quantum physics today. This title is clearly linkbait...

rat87 14y ago
> Please stop with the X higher level language can be faster than C unless you can challenge the limitations imposed by the laws of physics. Not which compiler is better. I can always find a better or worse C or JS compiler/JITter so that proves nothing. Turing equivalence and not even turing equivalence but 2 pieces of code with roughly the same functionality does not dictate the speed between them. You seem to be under some sort of misconception that two pieces of code have to be implemented in the same. For a long time tcl led the computer language shootout regex test because it has a wicked fast regex library(written in c I think). Nowadays the c version of that test uses the tcl regex library and is beaten by v8(chrome) javascript's even faster regex library(written in c++). It is hard to beat c in speed and it is rare when something implemented in a different language does it. When it does it is frequently do to the algorithm/way it was implemented. The reason that this is so is that few people care enough about beating c with c++ being the only real contender. if you are careful you can beat c code with c++(almost all c++'s slower features do not slow it down if not used) add that to some cool compile time tricks with template metahackery and c++'s better inlining and you can do it. The other part about beating c is complexity. Certain things are complex to implement in c. There is a reason we use so little assembly anymore, it's possible for smart people to beat optimizing compilers for certain cases but the general case isn't so pretty for it. Also with the rise of more/cheaper memory for gc to work well(and when it does it goes like hell on wheels) and parallel computers(parallelism being much easier in some languages then c) we may see it more soon. People have been saying that for a while but still.
- goggles99 14y ago
  >Turing equivalence and not even turing equivalence but 2 pieces of code with roughly the same functionality does not dictate the speed between them. You seem to be under some sort of misconception that two pieces of code have to be implemented in the same I am merely pointing out that there is overhead with every VM. This is especially true with every current JITted JavaScript in use today (more so than with the JVM and CLR). So how could it possibly be faster if both implementations use an equal amount of optimization otherwise. How is this even ever an argument?

afhof 14y ago

Why does everyone keep saying Doing X in Language Y is faster than X in Language Z? Really they are comparing compilers, not languages. Everyone seems to just keep making potshots at Language Z.

camus 14y ago

INFLAMMATORY headline for self-branding and publicity , doesnt go much further. Yes javascript can be fast but in the end , having to write evals to gain performances demonstrate that there is something really wrong with that langage...

ben0x539 14y ago
I disagree!! Being able to use evals to dynamically generate code for unrolled loops (and other similarly specialized procedures) sounds like a pretty amazing tool, and I can't not consider having it readily available an advantage of Javascript compared to C.

username_taken 14y ago

This is only part of the picture. This version of the driver is much slower than the driver based on libmysqclient. See the benchmarks at the bottom. It's a more real world test combining both reads and writes. https://github.com/mgutz/mapper https://github.com/mgutz/mapper

agentultra 14y ago

I guess the hope of high-level languages is that you can build a more interesting vocabulary from complex concepts. http://www.pvk.ca/Blog/2012/08/27/tabasco-sort-super-optimal-merge-sort/ http://www.pvk.ca/Blog/2012/08/27/tabasco-sort-super-optimal... It seems that there's a lot of effort going into making languages, "faster than C." Perhaps we would all be better off working with languages that just give us better abstractions -- user vocabularies. Layers on layers. Don't get me wrong, C is the right language and a good tool for many situations. It's just that if you're going to extend the vocabulary then why do you have to change the implementation? If you want to optimize why optimize the compiler at such a low level? Either way I just want to say that it's an interesting conversation and I'm looking forward to seeing more.

chmike 14y ago

Check the code : https://github.com/felixge/node-mysql https://github.com/felixge/node-mysql Note: it uses node_buffer.cc which is some C++ code in node. So it is not exactly pure Javascript.

faragon 14y ago

No way. Even with equal-efficient code, there is an additional point that is often ignored: Data structures are way more simple in C, with less overhead, and with higher cache-hit ratio, because more data fits in CPU data cache. As example, gcj is as fast as g++ for code generation (both generating machine code, without virtual machine involved), however, in benchmarking appears to be slower, just because the data structures. If you tweak the Java code for use simpler data structures, e.g. integer or byte arrays, data overhead gets reduced, so memory cache hit increases, thus keeping similar performance to C/C++. Other cases, like Java bytecode running on a VM, even with great JIT like HotSpot, suffers also a lot because of data structures, so even when generated code is quite decent (runtime profiling, etc.), penalty is there, so code will suffer great penalty unless running with huge L3 cache (e.g. 32-48MB), being noticeable anyway no matter how much cache you add when having to do many memory indirections more. And of course, when comparing, you have to compare equivalent things, e.g. Java <-> C/C++ ports, and not completely different software with different implementation (e.g. optimized built-in string handling vs non-optimized C string handling -e.g. ASCIIz string handling is slow, because of stupid C string function implementation, not because the C language itself, being the reason of C strings not being used for high performance code, even when writting in C-).