Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's not Ruby that's slow, it's your database

berk.es

Post reply on HN
Print view View original

41–50 of 203 posts

Re: It's not Ruby that's slow, it's your database

#41

Post by bvirb »

The Sequel ORM (mentioned in this article) is absolutely amazing. There is a plugin for Rails to swap out ActiveRecord with it as well.

It does a good job of letting the DB do its job. Like you can define complex constraints on tables in your database and then the corresponding models will automatically detect them and have the related app-level validations. So you can keep more data integrity enforcement in the database where your transactional guarantees are but still have nice error messages in your app without duplication.

If you're looping over a collection of records it can detect if you call an association method on one of them and load the same association for all the records you're looping over in a single query, avoiding most N+1 issues.

Lots more cool stuff too. I haven't used ActiveRecord in quite a while, so I'm not sure whether it has since absorbed some of the Sequel behavior, but it's definitely worth a look.

Re: It's not Ruby that's slow, it's your database

#42

Post by riwsky »

pixl97 wrote: post #12
mrinterweb wrote: post #9

In my experience 9/10 web application performance problems are related to database interactions. Is the query using an index? Are you hammering your DB with 300 N+1 queries to render an API response. These are usually the biggest offenders when poor performance is observed. If you're interactions with you DB are bad, it doesn't matter what programming language you use, performance will be mostly equally awful regardl…

Bad indexing, no indexing, and fragmented indexes seem to cause no end of issues, and there always seem to be shortages of people capable of fixing it properly.

They’re out there—but I just ran EXPLAIN ANALYZE on my company’s search for them, and the query planner’s not too happy. It has to scan the entire resume heap before doing an on-site join with candidates, all while dealing with resource contention from queries of other employers. I know recruiters and e.g. triplebyte, stackoverflow all offer indexes to speed up this search, but in our case those indexes wouldn’t fit in cash.

Re: It's not Ruby that's slow, it's your database

#43

Post by rahimnathwani »

int_19h wrote: post #39
caladin wrote: post #24

Earlier quoted context omitted.

I agree but I think Hibernate is an extreme. There is a middleground, query builders, which enable dynamic query construction (e.g. dynamically appending filter predicates) with reduced cognitive load of something like Hibernate. I personally was heavily in the camp of "write raw queries ideally with code generation for statically typed/generated code" (as exist in Rust, Go, TypeScript, etc.), but I have since temper…

A pure query builder is just writing SQL on syntax tree level, more or less. This makes sense for the same reason why you want your macros to operate on ASTs and not raw text. But I would argue that it's still much closer to plain text SQL in the code than to any ORM.

Right, but it lives with your application code and has the same syntax as the application code. That's probably preferable to SQL stored procedures (which often live outside source control).

Re: It's not Ruby that's slow, it's your database

#44

Post by FridgeSeal »

falcolas wrote: post #31
jojobas wrote: post #18

Earlier quoted context omitted.

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.

Re: It's not Ruby that's slow, it's your database

#45

Post by twotwotwo »

This is kind of relevant now: Mastodon is seeing a lot of growth all the sudden, the popular server for it is in Rails, and scaling up quickly is a challenge for server operators used to the levels of traffic from two months ago.

Twitter did rewrite their frontend to JVM languages because it was enough of a bottleneck to be worth it. If you can get Mastodon substantially further by serving some views using something besides Rails, or even going around ActiveRecord in places, that is a pretty different short-term to-do list than if the immediate problems are in the data layer. (Long term you have to scale both of course!)

Re: It's not Ruby that's slow, it's your database

#46

Post by segfaultbuserr »

FridgeSeal wrote: post #44
falcolas wrote: post #31

Earlier quoted context omitted.

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/

Re: It's not Ruby that's slow, it's your database

#48

Post by ryantgtg »

spoiler wrote: post #26
drewbug01 wrote: post #13

I think my favorite part is buried in footnote 5: > Ironically, the performance issue becomes less articulated in this non-http, non-rails context, yet in these cases people generally dismiss ruby as option, for its performance-issues. Which, catch-22, is one of the reasons Ruby is hardly used outside of Rails (and/or Web). It's a shame that most people only write Ruby in the context of Rails. It's a lovely language,…

> It's a shame that most people only write Ruby in the context of Rails I fully agree with this! I used to use Rails for a few years (not professionally, FWIW), but didn't enjoy Rails that much. Even though, it's hands down the best "in class" framework, it beats anything in the JS or Python ecosystems (and claiming Django is anything close to Rails is just offensive to Rails). But anyway, I've yet to find something…

I agree. I’m not a professional developer, but I sometimes make bots/daily scripts, as well as scripts for work that are beyond Excel, and I always use ruby. My colleagues use python for similar work scripts, but to me they are painfully difficult to read and understand.

Re: It's not Ruby that's slow, it's your database

#49

Post by scottcodie »

Building your modern crud app is still incredibly hard to get right while still being performant in any language. IMO, neither ruby nor the database are at fault.

- Materialization pipelines are hard, especially ones that need transactional constraints.

- Passing async connections from the http request all the way through to the database is hard.

- Data distributions can change which can impact indexes, join ordering, and the optimal materialization pipeline.

Re: It's not Ruby that's slow, it's your database

#50

Post by rubyist5eva »

I’m a Rails developer by trade, been doing it for over a decade. Bad indexing and lazy N+1 are 90% of the performance problems in a typical rails application. The other 10% is when people do aggregates or joins in application code instead of sql. I absolutely despise ActiveRecord because it makes non-trivial aggregates a pain to write. Sequel is a much better ORM but good luck getting a team on board.
Post reply on HN