3 ms·

As your career goes on, you will likely eventually work on large production systems that are not idealized greenfield deployments - at this time, you will have

by devmor 1y ago

As your career goes on, you will likely eventually work on large production systems that are not idealized greenfield deployments - at this time, you will have to come to terms with the constraints of Network and I/O bounds, and your dreams of nano and milliseconds will be shattered. In particular, I welcome you to experience the lovely word of corporate VPNs, whose maintainers and developers seem to have latency expectations that have not changed in 30 years.

sfn42 1y ago
I'm currently working on one of those wonderful greenfield projects where the monkeys who put it together made these mistakes I describe and everything is slow. Website isn't even in production yet and everything takes 5+ seconds to load for no reason. Because they just store the data the way they got it which is shit, instead of shaping it into something sensible that allows efficient queries. And yes there's a corporate vpn and fire walls and vents and subnets and whatever else, but when I create a feature it doesn't take 5 seconds to load. It takes milliseconds to load. Because there's nothing in our environment that justifies this bullshit, the guys who built this app just suck. And I'm going to fix it like I always do. I have also worked on large production systems where I've fixed lots of performance issues. Often I can see them just by reading the code, I'll find some code that looks ass then I'll run it and sure enough it's slow. So I fix it. It doesn't take a profiler or micro optimization, it just takes some basic understanding of what we're doing. Some times slow code is justified, some times there's just a lot of processing to be done or a lot of network requests to send or something. But most of the time it's just devs who don't understand fundamentals.
- devmor 1y ago
  I’m sure your super awesome programming skills that fix infrastructure and eliminate network I/O are very cool!
  - sfn42 1y ago
    I'm not claiming to eliminate network transfer times. Sending a web request takes some time. But it doesn't take seconds, it takes anywhere from a few to a few hundred milliseconds, given that the request size is relatively small. If you're sending megabytes or gigabytes then obviously it takes longer. So if you have a website and a backend, the most basic request will be fast. Make an endpoint that just returns hello world, a request to this endpoint will generally take a number of milliseconds. Maybe 10, maybe a few hundred, something like that assuming a decent connection. That's the round trip time, including overhead from protocols and auth etc. Now you know the best case scenario - when you create a real endpoint that actually does something useful it will be slower. How much slower depends on what you are doing and how. That is what I am talking about. If you send 50 requests from your backend to various other services then obviously it's going to take a lot more time, so we want to avoid sending a lot of requests - especially in series, where the first request has to complete before the next one etc. We also want to avoid doing a lot of heavy processing. You can do a large amount of processing with no discernible performance impact, but at some point and especially with bad algorithms this processing time can explode and make your system slow. For example I once looked at some code to generate a report that took 25 minutes to run. It was getting two lists of objects and combining them by iterating through the first one and linear searching the other for a match by id. The time complexity of this is O(n^2). I turned the other list into a dictionary which allows O(1) lookup, eliminating the O(n) linear search, making the overall time complexity O(n) and the report generated in less than 5 minutes. Still painfully slow by my standards, and I'm sure I could have optimized it further if I didn't have more important tasks to work on, but it's a pretty good improvement from a few minutes of work. Another common culprit is just sending too much data. I've seen websites where a request returns huge Json documents of multiple megabytes, then uses a tiny fraction of the data. By changing the system so that the website only fetches the data it needs you can reduce the request time from seconds to milliseconds. I hope this gives you a better idea of what I'm saying.
    - devmor 1y ago
      I don't really know how else to lead you to understand that when you query a data source you do not have control over, through a network you do not have control over, you cannot make the interface work faster than the response from that data source. No matter how good your programming skills are, your endpoint cannot return data faster than it retrieves it.

by devmor 1y ago

sfn42 1y ago

I'm currently working on one of those wonderful greenfield projects where the monkeys who put it together made these mistakes I describe and everything is slow. Website isn't even in production yet and everything takes 5+ seconds to load for no reason. Because they just store the data the way they got it which is shit, instead of shaping it into something sensible that allows efficient queries. And yes there's a corporate vpn and fire walls and vents and subnets and whatever else, but when I create a feature it doesn't take 5 seconds to load. It takes milliseconds to load. Because there's nothing in our environment that justifies this bullshit, the guys who built this app just suck. And I'm going to fix it like I always do. I have also worked on large production systems where I've fixed lots of performance issues. Often I can see them just by reading the code, I'll find some code that looks ass then I'll run it and sure enough it's slow. So I fix it. It doesn't take a profiler or micro optimization, it just takes some basic understanding of what we're doing. Some times slow code is justified, some times there's just a lot of processing to be done or a lot of network requests to send or something. But most of the time it's just devs who don't understand fundamentals.

devmor 1y ago
I’m sure your super awesome programming skills that fix infrastructure and eliminate network I/O are very cool!
- sfn42 1y ago
  I'm not claiming to eliminate network transfer times. Sending a web request takes some time. But it doesn't take seconds, it takes anywhere from a few to a few hundred milliseconds, given that the request size is relatively small. If you're sending megabytes or gigabytes then obviously it takes longer. So if you have a website and a backend, the most basic request will be fast. Make an endpoint that just returns hello world, a request to this endpoint will generally take a number of milliseconds. Maybe 10, maybe a few hundred, something like that assuming a decent connection. That's the round trip time, including overhead from protocols and auth etc. Now you know the best case scenario - when you create a real endpoint that actually does something useful it will be slower. How much slower depends on what you are doing and how. That is what I am talking about. If you send 50 requests from your backend to various other services then obviously it's going to take a lot more time, so we want to avoid sending a lot of requests - especially in series, where the first request has to complete before the next one etc. We also want to avoid doing a lot of heavy processing. You can do a large amount of processing with no discernible performance impact, but at some point and especially with bad algorithms this processing time can explode and make your system slow. For example I once looked at some code to generate a report that took 25 minutes to run. It was getting two lists of objects and combining them by iterating through the first one and linear searching the other for a match by id. The time complexity of this is O(n^2). I turned the other list into a dictionary which allows O(1) lookup, eliminating the O(n) linear search, making the overall time complexity O(n) and the report generated in less than 5 minutes. Still painfully slow by my standards, and I'm sure I could have optimized it further if I didn't have more important tasks to work on, but it's a pretty good improvement from a few minutes of work. Another common culprit is just sending too much data. I've seen websites where a request returns huge Json documents of multiple megabytes, then uses a tiny fraction of the data. By changing the system so that the website only fetches the data it needs you can reduce the request time from seconds to milliseconds. I hope this gives you a better idea of what I'm saying.
  - devmor 1y ago
    I don't really know how else to lead you to understand that when you query a data source you do not have control over, through a network you do not have control over, you cannot make the interface work faster than the response from that data source. No matter how good your programming skills are, your endpoint cannot return data faster than it retrieves it.