5 ms·

Not surprising. Databases are built to be really efficient, and with enough hardware, they can forgive a lot. Mediocre developers can produce a lot of "workin

by kemiller2002 6y ago

Not surprising. Databases are built to be really efficient, and with enough hardware, they can forgive a lot. Mediocre developers can produce a lot of "working" code if they stand on the shoulders of giants. (Not saying you or your team was mediocre, I'm just saying that I've seen really bad code run a lot of business processes. At the end of the day, it worked and the company made money.)

pjmlp 6y ago
Just like I keep seeing plenty of mediocre teams doing for loops over GB of downloaded data and pegging Webserver CPUs for stuff that should have stayed on the DB. Usually that is one of the things I end up fixing when asked for performance tips, other is getting rid of ORMs and learn SQL.
- kemiller2002 6y ago
  Oh don't get me wrong, there is a time and a place for everything. There are many things that should be in the database, and there are a lot of people that avoid it because they don't want to learn SQL. You can have really good reasons and elegant code in SQL. I'm merely saying when someone immediately says, "that's dumb, you shouldn't do that," they aren't looking at the whole picture possibly and it was the choice that got the programming running which is important.
- jacques_chester 6y ago
  I did a take-home exercise earlier this week. They provided access to a database and said << do thing >>. Implied was that I should << do thing >> with a program rather than a query. One of my solutions used Golang. It pulled data, looped a lot, then put results back. It took approximately 4 minutes. I included a second solution, using SQL. It selected into the results table with a little bit of CTE magic. It took approximately 600ms.
  - bartread 6y ago
    Interesting, and I've seen and implemented similar optimisations plenty of times. The right query in the right place at the right time can make all the difference. Did you hear back from them with a positive response?
    - jacques_chester 6y ago
      Not yet, but it's a small firm. I trust the people involved and I don't mind giving them some time to go over it.
      - bartread 6y ago
        Well, best of luck: I hope you get the job.
- NicoJuicy 6y ago
  ORM's aren't that slow, they are quick to develop. When you see a bottleneck, you could use 2 systems ( eg. EF by default and Dapper when doing optimizations)

pjmlp 6y ago

Just like I keep seeing plenty of mediocre teams doing for loops over GB of downloaded data and pegging Webserver CPUs for stuff that should have stayed on the DB. Usually that is one of the things I end up fixing when asked for performance tips, other is getting rid of ORMs and learn SQL.

kemiller2002 6y ago
Oh don't get me wrong, there is a time and a place for everything. There are many things that should be in the database, and there are a lot of people that avoid it because they don't want to learn SQL. You can have really good reasons and elegant code in SQL. I'm merely saying when someone immediately says, "that's dumb, you shouldn't do that," they aren't looking at the whole picture possibly and it was the choice that got the programming running which is important.
jacques_chester 6y ago
I did a take-home exercise earlier this week. They provided access to a database and said << do thing >>. Implied was that I should << do thing >> with a program rather than a query. One of my solutions used Golang. It pulled data, looped a lot, then put results back. It took approximately 4 minutes. I included a second solution, using SQL. It selected into the results table with a little bit of CTE magic. It took approximately 600ms.
- bartread 6y ago
  Interesting, and I've seen and implemented similar optimisations plenty of times. The right query in the right place at the right time can make all the difference. Did you hear back from them with a positive response?
  - jacques_chester 6y ago
    Not yet, but it's a small firm. I trust the people involved and I don't mind giving them some time to go over it.
    - bartread 6y ago
      Well, best of luck: I hope you get the job.
NicoJuicy 6y ago
ORM's aren't that slow, they are quick to develop. When you see a bottleneck, you could use 2 systems ( eg. EF by default and Dapper when doing optimizations)