91–100 of 106 posts
It gave an example where the compiler's knowledge that something is an immutable array means better optimization. Which you can't express in C.
Earlier quoted context omitted.
Can you explain more what you mean about SQLite having roughly its own VM?
See: http://www.sqlite.org/different.html Money quote about half-way down the page: "SQL statements compile into virtual machine code" Every SQL database engine compiles each SQL statement into some kind of internal data structure which is then used to carry out the work of the statement. But in most SQL engines that internal data structure is a complex web of interlinked structures and objects. In SQLite, the compil…
Earlier quoted context omitted.
Can you explain more what you mean about SQLite having roughly its own VM?
There are also details and examples at http://www.sqlite.org/vdbe.html Things have changed a bit since then, but not much. SQLite's API is very different than regular databases because it is a library operating in the same process. In particular it does not calculate all result rows for a query up front (that wouldn't be very 'Lite') but instead calculates the next matching row as you ask for it. Consequently the int…
That sounds like SQL cursors?
Earlier quoted context omitted.
Yep. The usual "Program X is faster in C than Java" gets a barrage of "That's because you know C better". Shawn is a performance-obsessed Java expert, Eclipse committer and longtime Google coder who works on JGit. If he says Java is slower than C at this, then Java is slower than C at this. EDIT: but as wcoenen points out, this was written in 2009 and Java 1.7 does a better job with some of this.
He's an expert you say? That was certainly not my expectation from the article. (1) Blind faith in Generics. This alone screams newb to me. He says that he got better performance with a custom data structure (no shit sherlock) but then seems deeply surprised by this. Duh. Okay, well, obviously he's relatively new to Java, but hey, he could still be a performance expert. (2) Never mentions the biggest weapon in the C…
In theory, any VM language will be slower than a memory managed app.
Then again, the dragon book is hard :)
All the points are valid but they are peculiar to Java, not to all managed high-level languages. C#/.NET, for example, have unsigned types, value-type arrays and structs, memory mapped files and specialized collections. As an example, the C# port of Sqlite is sometimes faster than the C version on queries, although updates are slower, despite Sqlite is a highly optimized C library. EDIT: link http://code.google.com/p…
Slightly offtopic, but I wonder how much overhead in those benchmarks comes from calling native code from .NET runtime? An interesting data point could be benchmarking equivalent implementation in C or C++, avoiding the overhead of native-managed transition.
Otherwise, unsafe regions have practically zero overhead, and they are close enough to the metal.
All the points are valid but they are peculiar to Java, not to all managed high-level languages. C#/.NET, for example, have unsigned types, value-type arrays and structs, memory mapped files and specialized collections. As an example, the C# port of Sqlite is sometimes faster than the C version on queries, although updates are slower, despite Sqlite is a highly optimized C library. EDIT: link http://code.google.com/p…
Additionally, C# collections do not need to box. List uses an actual array of integers as its backing store instead of an array of objects that contain boxed copies of the integers. There is a port of JGit to .NET called NGit, which is what we use for MonoDevelop. The port is maintained with an automatic tool that converts Java code to C# code, you can find it here: https://github.com/slluis/ngit
Yes, that's what I meant with specialized collections :)
BTW, I didn't know about the awesome NGit, automatic conversion from Java is really impressive!
Earlier quoted context omitted.
See: http://www.sqlite.org/different.html Money quote about half-way down the page: "SQL statements compile into virtual machine code" Every SQL database engine compiles each SQL statement into some kind of internal data structure which is then used to carry out the work of the statement. But in most SQL engines that internal data structure is a complex web of interlinked structures and objects. In SQLite, the compil…
Off-topic but relevant: I've been looking for info on just how database software does what it does. Ie from parsing the SQL query to hitting the disk, and everything in between. Anyone got any links or books?
Earlier quoted context omitted.
See: http://www.sqlite.org/different.html Money quote about half-way down the page: "SQL statements compile into virtual machine code" Every SQL database engine compiles each SQL statement into some kind of internal data structure which is then used to carry out the work of the statement. But in most SQL engines that internal data structure is a complex web of interlinked structures and objects. In SQLite, the compil…
Off-topic but relevant: I've been looking for info on just how database software does what it does. Ie from parsing the SQL query to hitting the disk, and everything in between. Anyone got any links or books?
I strongly recommend you read one such book more or less end-to-end.
HN: As with other areas of computer science, there is often a "canonical" book, like TAOCP or CLRS on algorithms. Is there any such book for databases?
I find it kind of interesting that in Haskell, which is arguably even higher level than Java, most of these optimisations are eminently possible.. EDIT: This obviously came across a bit as language fanboyism, so I guess I should mention that the language features that let you do many of them let you shoot yourself in the foot just as easily as you can in C, and you can certainly argue that with a strong FFI you might…
I've heard the argument before that in need, one can use a FFI to optimize bottlenecks in high-level code, but I've never understood. Won't using a high-level language incur an omnipresent speed slump? And even if a bottleneck exists, how would using a FFI remedy crucial problems in the language, like the absence of unsigned types or that all types are boxed. The types will have to be unboxed anyway, so whether that…
Not sure that is true. Just look at pypy(http://pypy.org/) which claims that run-time optimizations in the interpreted interpreter outperforms the C interpreter, and quite significantly in many cases. So I don't think it's true that high-level languages are always slower. It has a lot to do with the optimizations you can do at run-time. There is also an interesting paper on developing an OS based on run-time code synthesis for optimizing performance (http://valerieaurora.org/synthesis/SynthesisOS/). The major drawback of languages like C is that it can only optimize things at compile-time. I think as projects get larger and we move towards parallel structures and algorithms the need for languages that support run-time optimizations will be greeter.
Earlier quoted context omitted.
See: http://www.sqlite.org/different.html Money quote about half-way down the page: "SQL statements compile into virtual machine code" Every SQL database engine compiles each SQL statement into some kind of internal data structure which is then used to carry out the work of the statement. But in most SQL engines that internal data structure is a complex web of interlinked structures and objects. In SQLite, the compil…
Off-topic but relevant: I've been looking for info on just how database software does what it does. Ie from parsing the SQL query to hitting the disk, and everything in between. Anyone got any links or books?
Bonus: in the sqlite command line tool, putting "EXPLAIN " before a query will dump out the VM commands that the query was converted to, without executing them.