Hacker News Reader

Comment by jojobas | Hacker News Reader

From my experience with Python and Ruby, it's not the database itself, it's the database driver that spends quite some time on serialization and deserialization every time you want to send around some data, even more so when you pack some objects to store as semistructured/json/xml. So no, it's not the database, it's your interpreted language.

View on HN

Before we proceed, are you aware that a lot of popular database drivers for Ruby (and Python? not sure) implement the performance-critical bits in good old natively compiled C?

For example, the Ruby postgres gem: https://github.com/ged/ruby-pg/tree/master/ext

(I wasn't sure until I checked just now, so I'm not questioning your familiarity with the tech. Just not sure if that's commonly known)

    So no, it's not the database, it's your interpreted language.

Or it's your developers.

If you're moving enough data over the wire that application-side serialization/deserialization becomes an issue, often this is because developers are retrieving a whole truckload of records when they really only ought to be returning one.

Even in a fast application language, this is a problem. You're still burning extra CPU cycles, you're still allocating extra RAM, you're moving the same amount of extra data "over the wire", and you're still consuming extra database resources.

Of course, there truly are many use cases where you might want to move a truckload of data between your application and your database, and do some heavy crunching on the application side. I wholeheartedly agree Ruby is not ideal for that.

Marshalling the result into python or ruby objects is expensive no matter how you do it, and that cost is due to the programming language you need to marshal to, the logic being implemented in C can't help that.

Languages aren't interpreted, implementations are.

It's safe to call a language for which there's no production compiler an interpreted language.

Well, that’s neither Python nor Ruby. Both compile their code, and can do so ahead of time too.

None of the major Python implementations do any AoT compilation.

Python is probably the poster-child language of "interpreted". It's run, line-by-line through an interpreter, and turned into byte-code, which is executed by the VM. There's no compilation, and in CPython, very little optimisation. PyPy is obviously different on that last point as it's a JIT, but the larger point still stands.

> It's run, line-by-line through an interpreter, and turned into byte-code, which is executed by the VM.

Just a small technical correction: you can pre-complie to .py source files to .pyc bytecode files without waiting for the interpreter to do it line by line, many distro package managers already perform this step automatically when a package is installed. Though you're right in the sense that it doesn't really improve performance, CPython itself is the slowest part, not bytecode generation.

> There's no compilation, and in CPython, very little optimisation.

+1. This was actually a deliberate design choice [0]. Guido van Rossum himself said, "Python is about having the simplest, dumbest compiler imaginable." CPython was designed for ease of learning and use, it was never designed to be a high-performance language. Pure Python code (without C extensions like NumPy) can never be good at number-crunching tasks.

[0] https://nullprogram.com/blog/2019/02/24/

There are still some basic optimizations the Python compiler makes. It has, for example, a keyhole optimizer, and some built in optimizations around integer objects to name two.

It’s nothing too fancy, but it still does the basics.

GraalVM?

Reply on news.ycombinator.com