3 ms·

This post is the reason why developers deal everyday with horrible code that is apparently 'fast'. Don't start by making your system fast, start by making it w

by fleitz 14y ago

This post is the reason why developers deal everyday with horrible code that is apparently 'fast'. Don't start by making your system fast, start by making it work, then refactor it so it's clean. If it's still not fast enough think about upgrading the hardware. Also, there's something called a profiler: use it. It's really amazing what $200 of RAM will get you in terms of performance, ditto for $2000 worth of SSDs. Then add caching, and yes, if you made your site 'fast' to begin with you now have two problems. If you made your site 'properly' then it shouldn't be a big deal to add it in. Most of the reason Google is fast is that they have an ungodly amount of hardware. Google can put its hardware close to you, most startups cannot afford to put their hardware close to their users. Fast is what makes you spend a week tracking down pointer manipulation problems, deadlocks, race conditions, etc, instead of lock free data structures, immutable values, closures and higher order functions. At least now we have CPUs with 16 cores so the pointer kids are finally realizing how moronic portable assembler really was for making anything other than operating systems. I'll take code that's right over fast any day of the week. PS. Code that's built right is usually faster anyway.

jiggy2011 14y ago
A lot of the slowness for most sites comes from the client side, not the server side. Ads, tracking scripts and UI elements done in jQuery when you could have just beem HTML strings. Using a CDN is also a cost effective way of putting stuff close to your users in cases where the asset transfer is the bottleneck. If processing is the bottleneck then adding geographically distributed hardware isn't going to help too much. In my experience until you get into really crazy micro optimisations the clean way to do something is often relatively fast too. I've much more often seen code that is horribly slow and horribly messy than just one of those.
- deleted 14y ago
  [deleted]
voidlogic 14y ago
I agree, assuming your bottle neck is server side (which is often not the case): Need to make your huge app faster? 1. Have a well structured, correct design. 2. Optimize IO (file, network, database, etc) 3. Minimize in memory usage and copying 4. Replace your algorithms with ones with better runtime complexity characteristics. 5. Verify the granularity of your multi-threading. A. To big of "chunks" will lead to under utilization B. To small of chucks will lead to excessive communication overhead. 6. Replace the 10% most executed portion of your program with java native method, cGo function, C/C++ inline assembly, SSE instructions, etc etc. 7. Analyze your program for cache sizing and interactions. Ideally the application should be profiled between every step, don't be afraid to branch. Like fleitz said, don't skimp out on the hardware, but at the same time hardware improvements do not typically result in the same kind of multi-order of magnitude improvements that software changes do. But they are easier and cheaper and should be considered low hanging fruit. If performance is really the bottom line, running on non-virtual/phsyical hardware can help make some page table/hypervisor issues go away- as un-hip as that is.
- fleitz 14y ago
  IO is a huge one, most apps aren't CPU bound, they are IO bound. Those that aren't IO bound are latency bound. Those that are CPU bound are usually IO/latency bound on memory. If one can keep a modern Core i7 busy crunching numbers they are a God amongst mere mortals.
  - zobzu 14y ago
    if you over engineer stuff enough, don't worry, it'll crunch numbers in loop for a while ;) Last script I wrote - in about 20 lines of actual bash calling C programs which I know are well written, was performing the analysis of a 400meg file in about 15s. File was in fs cache (you know, Linux has an actual decent fs cache, unlike some other kernels..). Anyway, I then realized 2 people coded the same script already, one using perl, one using python. I sort of expected those would be slow, overengineered and what not after a quick look at the code. Then I decided I couldn't bad mouth stuff like this (even if I'm generally just telling this to myself) without giving it a chance. python took 50s, perl took about 2 min (yeah given perl's performance with strings, I was rather surprised, this must have been pretty poorly done). Each of these programs had about 500 lines of code (!!!). Ridiculous. Unfortunately, that's seems to be the standard these days. And I find this to be a perfect example, regardless of the language. No thinking => spend a long time writing a program with "nice classes" and stuff => its magnitudes slower than a non-optimized but properly designed program is. Thinking about proper design, knowing how your language, runtime, libs, kernel works at least in the big lines => (much) quicker to write the program => decently fast, and you have more time to make it even faster now.
meric 14y ago
Dealing everyday with horrible code that is apparently 'fast' has got to be better than dealing with horrible code that is horribly slow. Management sometimes doesn't care about code quality, but it's easier to make a case for refactoring by saying improving performance will improve time users spend on the site and thus improve revenue.
zobzu 14y ago
Nope. DESIGN your app, system, whatever properly. WITH performance in mind. Then when you code it, you DON'T need to deeply optimize stuff with unreadable hacks, that may or may not even work. But you DO need to make smart decisions. Almost every single piece of software i see that is slow, is slow because the underlying design is terrible. It's terrible because people are taught to "code now, optimize later", yet COMPLETELY discard having a decent design performance wise. Here's the trick. Once it's coded, you can't redesign the whole damn thing without losing a monstrous amount of time. So you just try to optimize the parts you can and that's that. And it's slow. Don't go optimize to gain 50ms right off the bat. But do write it properly so that it takes 1s if it can, and not 10min. Don't forget that there's a just middle in everything.

by fleitz 14y ago

jiggy2011 14y ago

A lot of the slowness for most sites comes from the client side, not the server side. Ads, tracking scripts and UI elements done in jQuery when you could have just beem HTML strings. Using a CDN is also a cost effective way of putting stuff close to your users in cases where the asset transfer is the bottleneck. If processing is the bottleneck then adding geographically distributed hardware isn't going to help too much. In my experience until you get into really crazy micro optimisations the clean way to do something is often relatively fast too. I've much more often seen code that is horribly slow and horribly messy than just one of those.

deleted 14y ago
[deleted]

voidlogic 14y ago

I agree, assuming your bottle neck is server side (which is often not the case): Need to make your huge app faster? 1. Have a well structured, correct design. 2. Optimize IO (file, network, database, etc) 3. Minimize in memory usage and copying 4. Replace your algorithms with ones with better runtime complexity characteristics. 5. Verify the granularity of your multi-threading. A. To big of "chunks" will lead to under utilization B. To small of chucks will lead to excessive communication overhead. 6. Replace the 10% most executed portion of your program with java native method, cGo function, C/C++ inline assembly, SSE instructions, etc etc. 7. Analyze your program for cache sizing and interactions. Ideally the application should be profiled between every step, don't be afraid to branch. Like fleitz said, don't skimp out on the hardware, but at the same time hardware improvements do not typically result in the same kind of multi-order of magnitude improvements that software changes do. But they are easier and cheaper and should be considered low hanging fruit. If performance is really the bottom line, running on non-virtual/phsyical hardware can help make some page table/hypervisor issues go away- as un-hip as that is.

fleitz 14y ago
IO is a huge one, most apps aren't CPU bound, they are IO bound. Those that aren't IO bound are latency bound. Those that are CPU bound are usually IO/latency bound on memory. If one can keep a modern Core i7 busy crunching numbers they are a God amongst mere mortals.
- zobzu 14y ago
  if you over engineer stuff enough, don't worry, it'll crunch numbers in loop for a while ;) Last script I wrote - in about 20 lines of actual bash calling C programs which I know are well written, was performing the analysis of a 400meg file in about 15s. File was in fs cache (you know, Linux has an actual decent fs cache, unlike some other kernels..). Anyway, I then realized 2 people coded the same script already, one using perl, one using python. I sort of expected those would be slow, overengineered and what not after a quick look at the code. Then I decided I couldn't bad mouth stuff like this (even if I'm generally just telling this to myself) without giving it a chance. python took 50s, perl took about 2 min (yeah given perl's performance with strings, I was rather surprised, this must have been pretty poorly done). Each of these programs had about 500 lines of code (!!!). Ridiculous. Unfortunately, that's seems to be the standard these days. And I find this to be a perfect example, regardless of the language. No thinking => spend a long time writing a program with "nice classes" and stuff => its magnitudes slower than a non-optimized but properly designed program is. Thinking about proper design, knowing how your language, runtime, libs, kernel works at least in the big lines => (much) quicker to write the program => decently fast, and you have more time to make it even faster now.

meric 14y ago

Dealing everyday with horrible code that is apparently 'fast' has got to be better than dealing with horrible code that is horribly slow. Management sometimes doesn't care about code quality, but it's easier to make a case for refactoring by saying improving performance will improve time users spend on the site and thus improve revenue.

zobzu 14y ago

Nope. DESIGN your app, system, whatever properly. WITH performance in mind. Then when you code it, you DON'T need to deeply optimize stuff with unreadable hacks, that may or may not even work. But you DO need to make smart decisions. Almost every single piece of software i see that is slow, is slow because the underlying design is terrible. It's terrible because people are taught to "code now, optimize later", yet COMPLETELY discard having a decent design performance wise. Here's the trick. Once it's coded, you can't redesign the whole damn thing without losing a monstrous amount of time. So you just try to optimize the parts you can and that's that. And it's slow. Don't go optimize to gain 50ms right off the bat. But do write it properly so that it takes 1s if it can, and not 10min. Don't forget that there's a just middle in everything.