4 ms·

on the other hand there are savings in development time, which might or might not be more expensive than cpu cycles in question. Especially for smaller scale pr

by mr__y 8y ago

on the other hand there are savings in development time, which might or might not be more expensive than cpu cycles in question. Especially for smaller scale projects. I'm not saying that 4 seconds to load a page is something to be happy about, but sometimes it's cheaper to "waste" cpu cycles than to spend more time developing faster solution.

willvarfar 8y ago
Although its really difficult to fathom how loading a webpage takes billions of cycles anyhow. It never used to. Remember the Internet in 2000? Pages are getting slower despite broadband speeds going through the roof and processors getting faster and there being so much more RAM etc.
- mcbits 8y ago
  Yep, I remember trying to optimize my 1-pixel spacer GIF from 53 bytes down to 47 bytes to lighten up the load of a 200KB page of random interwoven table, font, and center tags that took 30-60 seconds to download.
radicalbyte 8y ago
It only saves development time for the first version in my experience unless it's being used by an highly capable team. The months lost to the clueless developers massaging their horrible ORM code dominates in time. In the long term properly factored code wins; and lightweight ORMs have a place. Heavy ORMs (Hibernate, old Entity Framework) should only be used if you absolutely must have specific features and are incapable of building that into a more logical place in your code. Use a light weight ORM for simple CRUD actions (one with a small dependency graph). For performance critical create/update operations use stored procedures (just be careful with complex business logic; if you implement it, remember to test it). Use light weight ORM for mapping efficient SQL views to api/frontend. Use a workflow/async/job processing for anything which has to be long running or crosses system bounds (think credit card processing).
- jlebrech 8y ago
  you could start with an EASY query that's guaranteed to work, then AI could figure out a fast way as your app keeps running. it could be a module for postgresql for example.
pbowyer 8y ago
This. I am building an app and the listing screen is taking 4-5 seconds to fetch and display the database records. Why? The SQL query is complicated (7 joins due to filtering and permission restrictions), and on its own takes 1.7s to run. The ORM to enable pagination [0] runs this query twice plus a third query, adding up to over 3s. Plus other queries and rendering output (all times in debug mode). Does it matter? No - this screen will be accessed 30 times a day max. Better to have it work inefficiently and spend time on other tasks, than make it efficient - however much I want to. 0. https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/tutorials/pagination.html https://www.doctrine-project.org/projects/doctrine-orm/en/2....
collyw 8y ago
You are being downvoted, but it seems perfectly acceptable to many businesses. I wanted to improve the front page on my previous page (generating over 100 queries, taking between 1 and 4 seconds to load). In the end every other crappy new feature was given a higher priority.

by mr__y 8y ago

willvarfar 8y ago

Although its really difficult to fathom how loading a webpage takes billions of cycles anyhow. It never used to. Remember the Internet in 2000? Pages are getting slower despite broadband speeds going through the roof and processors getting faster and there being so much more RAM etc.

mcbits 8y ago
Yep, I remember trying to optimize my 1-pixel spacer GIF from 53 bytes down to 47 bytes to lighten up the load of a 200KB page of random interwoven table, font, and center tags that took 30-60 seconds to download.

radicalbyte 8y ago

It only saves development time for the first version in my experience unless it's being used by an highly capable team. The months lost to the clueless developers massaging their horrible ORM code dominates in time. In the long term properly factored code wins; and lightweight ORMs have a place. Heavy ORMs (Hibernate, old Entity Framework) should only be used if you absolutely must have specific features and are incapable of building that into a more logical place in your code. Use a light weight ORM for simple CRUD actions (one with a small dependency graph). For performance critical create/update operations use stored procedures (just be careful with complex business logic; if you implement it, remember to test it). Use light weight ORM for mapping efficient SQL views to api/frontend. Use a workflow/async/job processing for anything which has to be long running or crosses system bounds (think credit card processing).

jlebrech 8y ago
you could start with an EASY query that's guaranteed to work, then AI could figure out a fast way as your app keeps running. it could be a module for postgresql for example.

pbowyer 8y ago

This. I am building an app and the listing screen is taking 4-5 seconds to fetch and display the database records. Why? The SQL query is complicated (7 joins due to filtering and permission restrictions), and on its own takes 1.7s to run. The ORM to enable pagination [0] runs this query twice plus a third query, adding up to over 3s. Plus other queries and rendering output (all times in debug mode). Does it matter? No - this screen will be accessed 30 times a day max. Better to have it work inefficiently and spend time on other tasks, than make it efficient - however much I want to. 0. https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/tutorials/pagination.html https://www.doctrine-project.org/projects/doctrine-orm/en/2....

collyw 8y ago

You are being downvoted, but it seems perfectly acceptable to many businesses. I wanted to improve the front page on my previous page (generating over 100 queries, taking between 1 and 4 seconds to load). In the end every other crappy new feature was given a higher priority.