6 ms·

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 desig

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.

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.