Rails core - May 2005 - good news and bad news

Good news first: additional progress has been made on the performance front.

configuration 1: r121
configuration 2: r121 patched 20.5.05
page                               c1 real   c2 real c1 r/s c2 r/s c1/c2
/empty/index                       6.75525   1.60396  148.0  623.5  4.21
/welcome/index                     6.89044   1.78447  145.1  560.4  3.86
/rezept/index                      4.99573   1.85691  200.2  538.5  2.69
/rezept/myknzlpzl                  4.99592   1.86387  200.2  536.5  2.68
/rezept/show/713                  18.72658   4.34075   53.4  230.4  4.31
/rezept/cat/Hauptspeise           22.67481   4.63305   44.1  215.8  4.89
/rezept/cat/Hauptspeise?page=5    23.03755   4.67012   43.4  214.1  4.93
/rezept/letter/G                  21.66753   4.68094   46.2  213.6  4.63

So we''re nearing an improvement factor of 5!

Compared against the last report:

configuration 1: r121p.latest
configuration 2: r121 patched 20.5.05
page                               c1 real   c2 real c1 r/s c2 r/s c1/c2
/empty/index                       1.71983   1.60396  581.5  623.5  1.07
/welcome/index                     1.89244   1.78447  528.4  560.4  1.06
/rezept/index                      1.97025   1.85691  507.5  538.5  1.06
/rezept/myknzlpzl                  1.96929   1.86387  507.8  536.5  1.06
/rezept/show/713                   4.52896   4.34075  220.8  230.4  1.04
/rezept/cat/Hauptspeise            4.79957   4.63305  208.4  215.8  1.04
/rezept/cat/Hauptspeise?page=5     4.86045   4.67012  205.7  214.1  1.04
/rezept/letter/G                   4.84487   4.68094  206.4  213.6  1.04

This looks very good.

But now the bad news: a long time ago I decided against using link_to, 
as I observed it to be relatively slow (around the 0.95 release I 
think). Just for the fun of it, I decided to test the performance of 
link_to (with hash parameters). Here''s the data I got:

configuration 1: r121 patched 20.5.05
configuration 2: r121 patched 20.5.05 using link_to
page                               c1 real   c2 real c1 r/s c2 r/s c1/c2
/empty/index                       1.60396   1.60161  623.5  624.4  1.00
/welcome/index                     1.78447   1.78041  560.4  561.7  1.00
/rezept/index                      1.85691   1.86548  538.5  536.1  1.00
/rezept/myknzlpzl                  1.86387   1.86205  536.5  537.0  1.00
/rezept/show/713                   4.34075   5.34606  230.4  187.1  0.81
/rezept/cat/Hauptspeise            4.63305  12.28644  215.8   81.4  0.38
/rezept/cat/Hauptspeise?page=5     4.67012  13.28121  214.1   75.3  0.35
/rezept/letter/G                   4.68094  11.71969  213.6   85.3  0.40

Ouch. Ouch. Ouch. As you can see, using link_to can be up to 3 times 
slower than using a string path, seriously crippling performance. Most 
of the loss can be attributed to route.generate. Page 
"/rezept/cat/Hauptspeise?page=5" has 44 links on it, page 
"/rezept/show/713" has 13 links. So 13 calls account for 19% request
run
time? This is ridiculous. And I have only 2 entries in my route set. I 
don''t really want to know the figures for apps with 10 routes.

I think this must be improved before the 1.0 release, as a lot of people 
are using link_to all over the place.

My suggestion: make routing optional, please. And improve it too, for 
those that need it.

-- stefan

On May 23, 2005, at 6:59 AM, Stefan Kaes wrote:
> Ouch. Ouch. Ouch. As you can see, using link_to can be up to 3  
> times slower than using a string path, seriously crippling  
> performance. Most of the loss can be attributed to route.generate.  
> Page "/rezept/cat/Hauptspeise?page=5" has 44 links on it, page
"/
> rezept/show/713" has 13 links. So 13 calls account for 19% request  
> run time? This is ridiculous. And I have only 2 entries in my route  
> set. I don''t really want to know the figures for apps with 10
routes.
Thanks for the ongoing performance tuning, Stefan.  You''re going to  
have the snappiest Rails app going.

I have similar results with routing.  Nicholas Seckar is working on  
route.generate optimization; at last report he was generating upward  
up 10000 urls/sec.  Perhaps he could get you an early patch to test?

Best,
jeremy

Jeremy Kemper wrote:
> Thanks for the ongoing performance tuning, Stefan.  You''re going
to
> have the snappiest Rails app going.
>
Of course, I knew that when I started ;-)
> I have similar results with routing.  Nicholas Seckar is working on  
> route.generate optimization; at last report he was generating upward  
> up 10000 urls/sec.  Perhaps he could get you an early patch to test?
>
This sounds almost to good to be true, maybe he''s running it on a Cray?

I''d be happy to test it.

-- stefan

On Monday 23 May 2005 09:59, Stefan Kaes wrote:
> Ouch. Ouch. Ouch. As you can see, using link_to can be up to 3 times
> slower than using a string path, seriously crippling performance. Most
> of the loss can be attributed to route.generate. Page
> "/rezept/cat/Hauptspeise?page=5" has 44 links on it, page
> "/rezept/show/713" has 13 links. So 13 calls account for 19%
request run
> time? This is ridiculous. And I have only 2 entries in my route set. I
> don''t really want to know the figures for apps with 10 routes.
I have been working on a branch that improves route''s performance a
lot. The
test setup has 16 routes, and generates each url in 0.15ms.

If you''d like a copy of the code get in touch.

-- 

Nicholas Seckar aka. Ulysses