
If Your Website Or Search Isn't As Fast As Google, It's Too Slow - jessaustin
http://thecodist.com/article/if_your_website_or_search_isn_39_t_as_fast_as_google_it_39_s_too_slow
======
dfc
_40 years ago there was no Fedex, no email, no Twitter, and everything moved
at a slow pace._

Incorrect, Fedex was founded in 1971.[1] Its worth noting that the the founder
of FedEx also recognized that time was more important than ever before:

"The concept for what became Federal Express came to Fred Smith while he was
studying at Yale University. For a class there, he submitted a paper which
argued that in modern technological society time meant money more than ever
before"[2]

I understand what the author was going for but I do not understand starting a
piece with a bold and catchy introduction if you can't be bothered to check
your facts.

[1] <http://en.wikipedia.org/wiki/FedEx>

[2] <http://en.wikipedia.org/wiki/FedEx_Express>

~~~
greenyoda
The part about no e-mail is also wrong: the first ARPANET e-mail was also sent
in 1971:

<https://en.wikipedia.org/wiki/Email#Email_networks>

And did everything really move at a slow pace 40 years ago? Besides FedEx and
network e-mail being created, there were six lunar landings between 1969 and
1972, and society was being transformed by the sexual and civil rights
revolutions. In 1972 the Watergate scandal brought down the U.S. presidency
and Kernighan and Ritchie's book on C was published. Science and technology
and society were evolving rapidly, perhaps more rapidly than today.

~~~
zobzu
Arguably so, they weren't really slowed down by software and attention-sites
back then HN is one of those sites, mind you.

Few are the people who can restrain to use these less than 30min a week. And
heck, since everybody killed RSS feeds, there's no very good way to get access
to information quickly anyway.

Plus, since the content is rarely well researched, you generally gotta read
comments.

------
arocks
_The longer a slow system exists the more unlikely you could ever make it
faster, much less Googlespeed._

A very interesting debate on Premature optimization versus Profile-guided
Optimization could be had from this comment. Ideally, better algorithms and
efficient data structures could be chosen at the design stage to create a more
optimized solution. But does this approach always work?

In my experience, it often fails in a greenfield implementation. The reason
being the lack of understanding of the real performance bottlenecks. This is
usually revealed only after several iterations of profiling and optimizing
code (often revealing least expected spots).

But if it's fairly well known problem say relative ranking of a set of
hyperlinked documents, there is a lot of opportunity to study existing
literature and come up with a more efficient algorithm. Even then, once the
initial implementation is built, the task of making "a slow system faster"
needs to be done and often a never ending process.

So the conundrum is not often the need for speed being an primary criteria but
on lack of familiarity with the performance bottlenecks eliminate them from
the design stage itself.

------
jrussbowman
You can over optimize for speed too though. One of the past designs I had for
unscatter.com was to start pre rendering the base page and then loading in
results. The idea being get something in front of the user as soon as
possible.

Over all I found it actually delayed getting the actual content to the user.
It seemed faster, but was actually slower. In the end I've found in most cases
the apis I use return pretty fast and have just settled with getting the
content and displaying to the user as simply as possible. My daily experience
with the site has proven to me this works best.

IMHO if you're in the 1 second or less area for page display I don't think
you're going to run anyone off.

------
fleitz
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.

~~~
voidlogic
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
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
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.

------
markhenderson
[https://developers.google.com/speed/pagespeed/insights#url=h...](https://developers.google.com/speed/pagespeed/insights#url=http_3A_2F_2Fthecodist.com_2Farticle_2Fif__your__website__or__search__isn__39__t__as__fast__as__google__it__39__s__too__slow&mobile=false)

vs

[https://developers.google.com/speed/pagespeed/insights#url=h...](https://developers.google.com/speed/pagespeed/insights#url=https_3A_2F_2Fwww.google.com_2Fsearch_3Fq_3Dgoogle_2Bpagespeed_26aq_3Df_26oq_3Dgoogle_2Bpagespeed_26aqs_3Dchrome.0.59j0j60l2j59j0.1663_26sourceid_3Dchrome_26ie_3DUTF-8&mobile=false)

Get back to work! :) I would start by leveraging browser caching.

------
segmondy
If your Car is not as Fast as a Ferrari, It's Too Slow.

~~~
antman
In the business of driving other people for free, the guy with the Ferrari
wins all the clients

~~~
Falling3
And here I thought it was something capable of carrying more than two
passengers. I donno... like a bus?

~~~
antman
For free I'll take the Ferrari!

------
DrJ
I was hoping for something on "how" :(

