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

Best practices can slow your application down

stackoverflow.blog

Post reply on HN
Print view View original

81–90 of 187 posts

Re: Best practices can slow your application down

#81

Post by jbjbjbjb »

kodah wrote: post #25

When I was an SRE-SE I despised the term "best practices". Teams would come in telling me all about the new best practice with serverless, Kubernetes, secrets storage, or whatever. It was almost always like someone took a magnificent full Lego set and snapped off a wall and was like, "Hey, try this, it was useful to us." If it's not a protocol or standard recognized by one of the IEEE, IETF, or ISO then it's a tutori…

It’s a peeve of mine too. The phrase ‘best practice’ is thrown around far too often and it can be used as a way to shortcut objective analysis.

Re: Best practices can slow your application down

#82

Post by chovybizzass »

arcturus17 wrote: post #69
ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

I also found the "or similar practices that the industry seems to love" coming across as a bit vague and even arrogant. On the other hand, I think that they have earned bragging rights - we're talking about a site that has massive scale and reach, and has a reputation for being a very efficient system. I appreciate that people like them share their views, even if they are contrarian and a touch arrogant. > they chose…

they seem to love it...non-committal.

Re: Best practices can slow your application down

#83

Post by vp8989 »

sgtnoodle wrote: post #68
ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

Adding test coverage might indeed destroy their performance, in that they might expose where their system's bottlenecks are and realize that they've been focusing on the wrong things. When it comes to performance optimizations, folks' intuitions are almost always wrong. It's important to actually test and measure stuff like that. I think it's true in general that modern CPUs are insanely fast at executing code within…

It's hilarious that you are skeptical of the competence of the SO core devs. You should do a little further reading, there is lots of content available online from the core devs who actually "do the work" there (ie, not the people who wrote this fluffy blog post).

Re: Best practices can slow your application down

#84

Post by brown9-2 »

sgtnoodle wrote: post #51

The article makes the excuse that static (singleton) interfaces are inherently simpler and less resource intensive enough for it to be worth skipping regression testing (because testing that style of code is hard.) Reading between the lines, it sounds like maybe they know they've dug themselves into a very expensive hole to dig out of. I've jumped head first into codebases that made the same excuse, and to me it seem…

The post also presents a false choice between what’s known as “the singleton pattern” versus just allocating a single instance of the object and passing it around where needed:

> We don’t write a lot of these because our code doesn’t follow standard decoupling practices; while those principles make for easy to maintain code for a team, they add extra steps during runtime, and allocate more memory. It’s not much on any given transaction, but over thousands per second, it adds up. Things like polymorphism and dependency injection have been replaced with static fields and service locators.

“dependency injection” doesn’t require constantly allocating new instances of the things your classes need.

Re: Best practices can slow your application down

#85

Post by travisjungroth »

CraigJPerry wrote: post #26
beny23 wrote: post #13

Earlier quoted context omitted.

Oh absolutely, keeping things simple should never be restricted to just production code. Testing code should be simple too. The idea that tests inhibits refactoring I find problematic though. Good tests enable refactoring. If the tests are too complex for anyone to change the code, the the code is too complex. Any complex system should be composed of simple components. Now this applies to monoliths as well as microse…

>> If the tests are too complex for anyone to change the code, the the code is too complex In enterprise software, the pattern i see is specifically coupling rather than garden variety complexity. There’s a really pervasive idea that unit testing means 1:1 mapping of test class to production code class. To put it another way, there’s this really common but terrible idea that tests should map to your current implement…

> A related issue is no one ever deletes tests.

I think this is a huge problem. I’m not sure why it exists.

“If we have more tests it will be harder to change the code.” is an argument people make sincerely. Then... just delete the tests. If your argument against having these tests is you can imagine a point where they become a burden, just keep in mind that it’s really, really fast to delete code. “Untested” is a state we can get back to at any moment.

Maybe the tests will provide a lot of value until then. Maybe if we do a big refactor we’ll delete the old tests that are too low level and make new ones. That’s fine.

Re: Best practices can slow your application down

#86

Post by tleb_ »

scarmig wrote: post #54
acd wrote: post #20

Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…

Within the same data center, a network call doesn't need to have significant performance overhead; it can be on the order of a read from main memory. Still overhead, but for many SLOs it's irrelevant. The inherent cost of microservices is conceptual and organizational complexity, not runtime performance (though you can certainly build slow microservices, you can also build slow monoliths).

You might get similar throughput but the latency isn't comparable.

Re: Best practices can slow your application down

#87

Post by klingon78 »

ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

Something not mentioned but is a much bigger problem than performance for most is that if you write too many tests, you may be unable to easily upgrade/update to newer versions without a significant amount of work to update all of the tests.

You’re right to call out performance as a reason for testing. Unfortunately, though, it’s usually not that easy. A problem not found in testing may be the result of inexperience or lack of foresight in design, such as the assumption that another adapter service in front of that enterprise cloud service that only exists in production isn’t a bottleneck, or that your code that had 100% unit test coverage turned out to leave nasty half-updated data due to non-transactional services and was deadlock-prone with memory leaks.

Re: Best practices can slow your application down

#88

Post by vp8989 »

jbjbjbjb wrote: post #81
kodah wrote: post #25

When I was an SRE-SE I despised the term "best practices". Teams would come in telling me all about the new best practice with serverless, Kubernetes, secrets storage, or whatever. It was almost always like someone took a magnificent full Lego set and snapped off a wall and was like, "Hey, try this, it was useful to us." If it's not a protocol or standard recognized by one of the IEEE, IETF, or ISO then it's a tutori…

It’s a peeve of mine too. The phrase ‘best practice’ is thrown around far too often and it can be used as a way to shortcut objective analysis.

It's candy for beginner/intermediates who want to sound like they know what they are talking about.

Re: Best practices can slow your application down

#89

Post by Cthulhu_ »

ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

They're really not selling their codebase or practices to me to be honest. If their system is built like that it might have enough performance to run a top x site on only a handful of bare metal servers, but the article also implies there's a lot of "here be dragons" code - don't touch this, you are not clever enough to test this, and since we don't have tests, you might break it by touching it.

Which is just bad practice on the one hand, and elitist on the other.

I for one am thankful I don't have to work with those constraints, and I can adopt a better mindset - make it work, make it pretty, make it fast, for example. I think you cannot optimize a system if you cannot read and understand it.

Also note I explicitly said "system", not "codebase"; at a big enough scale, you can't look at performance as a factor of code, but of architecture and patterns. You need to be able to get figures from specific systems in the whole architecture, not individual lines of code. Make the architecture easy to analyze and optimize.

Re: Best practices can slow your application down

#90

Post by Cthulhu_ »

acd wrote: post #20

Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…

What do you mean "somewhere down the line"? This is already well-known, but what is also known is that vertical scaling, e.g. how much one machine can do, is limited.

When you get to a global, millions-of-requests-per-second system like e.g. Twitter, you've gone well beyond vertical scaling.

Know your problem, then pick a solution. I'll admit that the microservices architecture is overused and I'm sure that's what you're aiming at, and I fully agree with that. But I also feel like you cannot understand the scale of true 'web scale' companies and their application. I know I can't.

Post reply on HN