5 ms·

This may be a little OT (OT because the points raised in the study are totally valid and mine is just a comment) but for small companies and solo developers ORM

This may be a little OT (OT because the points raised in the study are totally valid and mine is just a comment) but for small companies and solo developers ORM or whatever that gets the job done quickly is the way to go. Most sites and web apps never even break a 100k/day hit mark for which I believe inefficiency may not be the biggest issue. But wasting a month tryig to write native Sql queries can hurt your project a lot more.

mnm1 8y ago
Even if you get 1 hit / day and that takes a long time to return, the ORM has failed your one customer. Inefficiency exists even at small scales with ORMs. If your developers don't know how to write SQL, let them learn. Or fire them if they won't.
- olavk 8y ago
  > Inefficiency exists even at small scales with ORMs ORMs are not inherently inefficient. And in my time I have seen plenty of n+1 style queries written with raw SQL.
  - mnm1 8y ago
    Lazy loading often fetches too little and eager loading too much. Most orms select all columns in all tables regardless of need. The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems, it's just a matter of how big, over a system without the orm. Since orms are superfluous, every line of code in them adds unnecessary overhead. They are indeed inherently inefficient by definition.
    - olavk 8y ago
      > The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems No they are not. Have you measured this in a real-world application? This overhead is negligible compared to the cost of the query itself. And without an ORM you still have to load the data into some kind of objects or data structures before you pass it to presentation, you will just have to write the code yourself. But yeah, lazy loading in a loop will kill performance. So don't do that.
      - NightlyDev 8y ago
        It's definetly not always going to be a problem, but sometimes it does. ORM is always slower than writing custom code, but it might be more than fast enough.
        olavk 8y ago
        Surely it depends on the custom code in question if it is faster or slower than the similar ORM logic? You may be able to write faster code, but unless you are Donald Knuth, you can't guarantee that any custom code you write will always be faster than some library.
- blattimwind 8y ago
  > Inefficiency exists even at small scales with ORMs. In other words, you have no idea what you're talking about.
  - mnm1 8y ago
    So the ORM taking many seconds for query overhead isn't a problem? This makes the web page served by this api many seconds slower. A second of slowness increases bounce rate by quite a bit and by two to three seconds, most visitors abandon the website. I guess that doesn't matter to you as you post a comment without substance and only an insult.
    - falsedan 8y ago
      I think you have bigger fish to fry than site performance if you're getting 1 hit per day.
      - mnm1 8y ago
        I think you completely missed the point here. If this happens for one customer, it happens for all of them and no amount of hardware thrown at the problem is going to solve this because it's already running on the best hardware available.
    - olavk 8y ago
      What ORM setup gives you "many seconds" overhead on a small website? Are you sure the ORM is to blame? I suspect you are doing something like lazy loading in a loop or joining/filtering on the client side.
  - dang 8y ago
    Personal attacks will get you banned here, regardless of how wrong someone else is. You've unfortunately been uncivil in at least one other comment in this thread too. Could you please (re-)read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and not use this site that way? The idea here is to post civilly and substantively, or not at all.
chasd00 8y ago
i always take the approach of get it functionally complete first then optimize for performance. It's easier to track optimization bugs (which can be nasty) and you always have something to revert to that at least works. I agree that 99% of all projects never push beyond what relational databases are capable of. I've seen developers who were tasked with writing basically a todo list say that they're going with a nosql database because RDBMs don't scale.
gldalmaso 8y ago
> But wasting a month tryig to write native Sql queries can hurt your project a lot more. Unless it would be the first contact a developer has with SQL, I really don't see how difference in time taken to query the database with an ORM vs SQL would be anything more than a couple of minutes, maybe an hour if you really have a hard time with it or your data model is really convoluted.
- blattimwind 8y ago
  This really depends entirely on what your application is doing and how it generates and processes queries. Some things are just annoying to solve without an ORM / "query builder" / SQL-AST (unless you write a small ORM yourself).
mamcx 8y ago
I build a web app for that is only used by maybe 3 persons. Still, inefficiency is a huge issue. I need to be close to desktop-like performance for data entry, and that requiere both insert/read performance (that are executed in the same block and compromise several queries) below 1 seconds. Request/seconds is not the metric that matter. Is the seconds/for user(s) main activity.
cleong 8y ago
Depends on the application. In e-commerce and I believe many other industries as well will depend on fast responses for conversions. For example, a page that loads ~2 seconds will start to lose bounce rates/ conversions. Of course full page cache is the first stopgap for this problem but you'll always have dynamic content.
wwweston 8y ago
I actually make this calculation for most projects that I work on -- what level of traffic do I expect this to see? If it's a back-office function or is limited to a few hundred clients at a time, I don't even worry about performance. But that said... writing native SQL queries wastes a month? Um, no. ORMs are convenient, but writing select, insert, update, and delete queries by hand isn't that hard. It's mildly verbose and you end up repeating yourself lots so it's annoying, particularly if you (like me) have the kind of programmer's mind that constantly wants to factor that out. But it's doable without adding a high factor to development time.
- golergka 8y ago
  Writing anything is fast. It's maintaining it that becomes a problem.

mnm1 8y ago

Even if you get 1 hit / day and that takes a long time to return, the ORM has failed your one customer. Inefficiency exists even at small scales with ORMs. If your developers don't know how to write SQL, let them learn. Or fire them if they won't.

olavk 8y ago
> Inefficiency exists even at small scales with ORMs ORMs are not inherently inefficient. And in my time I have seen plenty of n+1 style queries written with raw SQL.
- mnm1 8y ago
  Lazy loading often fetches too little and eager loading too much. Most orms select all columns in all tables regardless of need. The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems, it's just a matter of how big, over a system without the orm. Since orms are superfluous, every line of code in them adds unnecessary overhead. They are indeed inherently inefficient by definition.
  - olavk 8y ago
    > The query translation and hydration overhead of transforming the data into objects even in a fast language are always going to be problems No they are not. Have you measured this in a real-world application? This overhead is negligible compared to the cost of the query itself. And without an ORM you still have to load the data into some kind of objects or data structures before you pass it to presentation, you will just have to write the code yourself. But yeah, lazy loading in a loop will kill performance. So don't do that.
    - NightlyDev 8y ago
      It's definetly not always going to be a problem, but sometimes it does. ORM is always slower than writing custom code, but it might be more than fast enough.
      - olavk 8y ago
        Surely it depends on the custom code in question if it is faster or slower than the similar ORM logic? You may be able to write faster code, but unless you are Donald Knuth, you can't guarantee that any custom code you write will always be faster than some library.
blattimwind 8y ago
> Inefficiency exists even at small scales with ORMs. In other words, you have no idea what you're talking about.
- mnm1 8y ago
  So the ORM taking many seconds for query overhead isn't a problem? This makes the web page served by this api many seconds slower. A second of slowness increases bounce rate by quite a bit and by two to three seconds, most visitors abandon the website. I guess that doesn't matter to you as you post a comment without substance and only an insult.
  - falsedan 8y ago
    I think you have bigger fish to fry than site performance if you're getting 1 hit per day.
    - mnm1 8y ago
      I think you completely missed the point here. If this happens for one customer, it happens for all of them and no amount of hardware thrown at the problem is going to solve this because it's already running on the best hardware available.
  - olavk 8y ago
    What ORM setup gives you "many seconds" overhead on a small website? Are you sure the ORM is to blame? I suspect you are doing something like lazy loading in a loop or joining/filtering on the client side.
- dang 8y ago
  Personal attacks will get you banned here, regardless of how wrong someone else is. You've unfortunately been uncivil in at least one other comment in this thread too. Could you please (re-)read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and not use this site that way? The idea here is to post civilly and substantively, or not at all.

chasd00 8y ago

i always take the approach of get it functionally complete first then optimize for performance. It's easier to track optimization bugs (which can be nasty) and you always have something to revert to that at least works. I agree that 99% of all projects never push beyond what relational databases are capable of. I've seen developers who were tasked with writing basically a todo list say that they're going with a nosql database because RDBMs don't scale.

gldalmaso 8y ago

> But wasting a month tryig to write native Sql queries can hurt your project a lot more. Unless it would be the first contact a developer has with SQL, I really don't see how difference in time taken to query the database with an ORM vs SQL would be anything more than a couple of minutes, maybe an hour if you really have a hard time with it or your data model is really convoluted.

blattimwind 8y ago
This really depends entirely on what your application is doing and how it generates and processes queries. Some things are just annoying to solve without an ORM / "query builder" / SQL-AST (unless you write a small ORM yourself).

mamcx 8y ago

I build a web app for that is only used by maybe 3 persons. Still, inefficiency is a huge issue. I need to be close to desktop-like performance for data entry, and that requiere both insert/read performance (that are executed in the same block and compromise several queries) below 1 seconds. Request/seconds is not the metric that matter. Is the seconds/for user(s) main activity.

cleong 8y ago

Depends on the application. In e-commerce and I believe many other industries as well will depend on fast responses for conversions. For example, a page that loads ~2 seconds will start to lose bounce rates/ conversions. Of course full page cache is the first stopgap for this problem but you'll always have dynamic content.

wwweston 8y ago

I actually make this calculation for most projects that I work on -- what level of traffic do I expect this to see? If it's a back-office function or is limited to a few hundred clients at a time, I don't even worry about performance. But that said... writing native SQL queries wastes a month? Um, no. ORMs are convenient, but writing select, insert, update, and delete queries by hand isn't that hard. It's mildly verbose and you end up repeating yourself lots so it's annoying, particularly if you (like me) have the kind of programmer's mind that constantly wants to factor that out. But it's doable without adding a high factor to development time.

golergka 8y ago
Writing anything is fast. It's maintaining it that becomes a problem.