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

161–170 of 187 posts

Re: Best practices can slow your application down

#161

Post by klingon78 »

stonemetal12 wrote: post #157
klingon78 wrote: post #117

Earlier quoted context omitted.

I meant upgrading application frameworks, OS, etc., so it’s not a red herring. Those can inflict a lot of changes if you have a lot of tests affected.

Thus automated test time + automated test maintenance is usually less than manual test time + manual test maintenance. Mostly because execution time for automated tests is so much shorter than manual execution time that the higher cost of automated test maintenance is recouped and then some. The only way for framework\OS changes to impact that is if they happen often enough to make automated test maintenance "weigh"…

I don’t think we’re speaking the same language. I’m talking about how much time it takes to change the code in every unit test, etc. because you upgraded something that requires changing the test framework, and this library and that one, so you end up not only having to fix all of your production code, but all of the tests with their mocks, stubs, injections, annotations, xml config, etc. If you have thousands of tests, this can keep people from upgrading.

Re: Best practices can slow your application down

#162

Post by nlittlepoole »

pbowyer wrote: post #61
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…

I like RDS because I don't have to think about backups, replication etc but if I colocate the app server (web server, application code) and the database server on the same machine I see 1-2 orders of magnitude performance improvement in database-intensive apps. Replication is the same as usual; have another machine setup to replicate onto. The restriction is you can't fan out hundreds of application servers and half…

You might want to check this out then if you are on AWS https://litestream.io/

Re: Best practices can slow your application down

#163

Post by pjscott »

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…

I'd like to take this opportunity to encourage people to learn about sampling profilers. What they do is periodically record the program counter and call stack of a process, then aggregate these to get a picture of where the program was spending its time. With a low enough sampling frequency they can have negligible impact on the speed of the software being profiled, they require no changes to production code, and they operate with fine enough granularity that they can easily tell you if (for example) a particular polymorphic function call is adding significantly to the runtime of a hot loop.

Often all you need to do to find out what the real bottlenecks are is to point one of these profilers at a running program and look through the results. Super low effort, potentially big payoff.

Re: Best practices can slow your application down

#164

Post by pjscott »

bluGill wrote: post #126
arcturus17 wrote: post #69

Earlier quoted context omitted.

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…

> It sounds like they would've lost a lot of the conveniences that a framework like .net gave them. Would they have? It sounds like they put a lot of effort into bypassing the garbage collector by creating buffers up front and then never letting then reusing them so they can never be garbage collected. Best practice in embedded C code is to allocate buffers up front and then reuse them. The terminology in the above t…

> Once you lose garbage collection does .net give you anything over C++?

You don't need to lose garbage collection altogether. There's a middle ground here: if you can switch to manual buffer management for the most GC-heavy, speed-critical code, that still lets you use GC with impunity everywhere else.

Re: Best practices can slow your application down

#165

Post by shalmanese »

dustinmoris wrote: post #146
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…

100% agreed. This was a very poor article. They've basically gone with an overly expensive Microsoft stack which meant that from the beginning they were fighting the wrong fight. Instead of thinking about scale for best performance, they had to think about best cost for minimum scale. Furthermore they decided to bastardise their C# code to some fake low level untestable C dragon code which makes matters even worse. T…

> But no, they stuck with C# for god knows what reason

Mainly because Rust (2010) and Go (2009) weren't around when SO was first created (2008).

Re: Best practices can slow your application down

#166

Post by beny23 »

kybernetikos wrote: post #103
marcosdumay wrote: post #78

Earlier quoted context omitted.

> It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I can't take this any other way than a huge overstatement. I'm yet to find any such example where retrofitting it is orders of magnitude harder. Worst case it requires understanding the entire system again, and adding instrumentation here or there. That can be almost as hard as writing the entire system again, but usually…

I read that statement as orders of magnitude more difficult/expensive to retrofit testability as opposed to making the system testable at the start, not as opposed to creating the system.

Yes that’s what I meant

Re: Best practices can slow your application down

#167

Post by shalmanese »

klingon78 wrote: post #87
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…

> you may be unable to easily upgrade/update to newer versions without a significant amount of work to update all of the tests.

That's a code smell. Tests should only be updated to reflect a new understanding of the requirements of the system. If you're writing tests that are dependant on the implementation of code and not the behavior of code, then you're too tightly coupling your tests to your code.

Re: Best practices can slow your application down

#168

Post by beny23 »

marcosdumay wrote: post #78
beny23 wrote: post #14

Earlier quoted context omitted.

It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I’d argue that they were successful despite their approach not because of it. I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising. I really don’t think it’s a mode…

> It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I can't take this any other way than a huge overstatement. I'm yet to find any such example where retrofitting it is orders of magnitude harder. Worst case it requires understanding the entire system again, and adding instrumentation here or there. That can be almost as hard as writing the entire system again, but usually…

Speaking from experience, if you have to go back after many years of development, where most of the team that made the original design choices has left and want to make changes without breaking the system and discover that half of the system has no tests then it’s going to be difficult to even make the smallest of changes.

When you then decide that you need to retrofit good tests, it always becomes an exercise in trying to reverse engineer the requirements (because half the documentation has been lost or is so hopelessly out of date it may well be lost), then yes, making something well tested is very hard.

Having said that, it often worth doing it because how else are you going to have the confidence that you don’t break the system with every little change, but it very much is going to require much more effort than if it had been done in the first place.

Re: Best practices can slow your application down

#169

Post by jve »

martinald wrote: post #67
harg wrote: post #31

One thing that stood out to me was they wouldn't need necessarily need to optimize for performance if they didn't choose a stack whose costs increase massively as you scale. In many applications things like having a testable, easy-to-read, well-structured codebase can trump performance, and it's often worth sacrificing a bit of performance if it means it's easier to refactor and build new features.

I don't know why they went for SQL Server, .NET has had good support for other databases even back to 2009. I imagine that was a huge amount of their licensing cost. With .NET Core running so well on Linux now they would have no Windows Server licenses to worry about too. The first production version of .NET core was released in 2016. Even back in 2009 it was possible to run web apps on mono on linux too, I know a lo…

Because that was what the main developer and founder Jeff Atwood was familiar with. And he really liked the stack.

> Atwood: We are not personally going to be language agnostic, because we need to actually build the site. And in terms of people actually working on it, Joel's in an advisory role, I'm gonna be writing code, and then a friend of mine, Jarrod, I'll be working very closely with. So it's sort of like 1.5 developers, so I need to actually get things done. In order to do that, I'm gonna fall back on what I know, and what I know is essentially ASP.NET. So ASP.NET is gonna be the platform. And I actually really like ASP.NET.

Episode 003 April 29, 2008, from the StackOverflow podcast.

https://stackoverflow.fogbugz.com/default.asp?W56

Analysis from 2008 about Scaling Up / Out. Electricity also is something you can't ignore.

https://blog.codinghorror.com/scaling-up-vs-scaling-out-hidd...

Ah, sorry, this is a discussion about SQL Server being expensive rather than .NET stack.

Re: Best practices can slow your application down

#170

Post by stephenbez »

orclev wrote: post #138
arcturus17 wrote: post #127

Earlier quoted context omitted.

Yea they mention that in the post. I agree with you that it seems like a self-imposed limitation. At the same time, it makes one think how said limitations can actually foster creativity and efficiency. They mention in the post - they constantly gloat about this - that they could run SO on one or two machines. I'd imagine that said machine would need to be a behemoth and not a t3.micro, but intuitively I feel that th…

Eh, not sure that follows. Here's the thing, costs aren't linear. If you do what AWS does and create some artificial "compute units" as a sort of fungible measure of processing power, what you'll find is that the sweet spot for price per compute unit is a medium power system. The current mid-range processors tend to be slightly more expensive than the low-end processors, but significantly cheaper than the high-end pr…

> If you do what AWS does and create some artificial "compute units" as a sort of fungible measure of processing power, what you'll find is that the sweet spot for price per compute unit is a medium power system.

At least when I look here the costs are linear.

E.g. c5.2xlarge is double a c5.xlarge, and a c5.24xlarge is 24 times higher than a c5.xlarge.

https://aws.amazon.com/ec2/pricing/on-demand/

Post reply on HN