Hi, Thanks for your help. Caching is a must in a production environment anyway. For a while I tried prewarming caches also. After deployment, I am crawling hit expected pages.
I recently decided to stop server side rendering completely to maximize the performance. But client side javascript is suicidal even with the best libraries. Then I came upon an OhMyGod solution. So dry, so expressive, so easy to debug. It was Elm. If you look at a few examples then you'll see what I mean: Simple building block examples to show ease of programming: http://elm-lang.org/examples Full application show cases: http://builtwithelm.co/ After seeing that client side could be stupidly easy, I am studying Elm now. I advice everybody to have an objective peek at the examples. Because Elm is a functional language, there is no way to create untraceable bugs. With elm client side and json serving, I could achieve 70* ms* while using Hobo. PS. While I am at performance, I just tried Elixir/Phoenix. I re-implemented in Elixir and I got 13 ms! Total controller and page rendering time was 250 micro seconds. I was making 13 ms just because of postgres. Going to Elixir is a productivity suicide because while Elixir/Phoenix is completely Rails like (yes, everything that makes Rails Rails is available), nobody has done a Hobo for it :) . I will start day dreaming Hobo for Elixir :) On Friday, August 28, 2015 at 8:32:19 AM UTC+2, umuro wrote: > > Recently I was observing where I am loosing my sites performance. For a > show page, I saw those numbers > > - DRYML 110 ms > - Controller 47 ms > - Record.find 9 ms > - User.find 5 ms > > This is how time is spent in serving that very page. > > It's clear that I need to optimize my controller. However, the time loss > in DRYML is huge! > > And this is not because of DRYML. Because of me. However, by simply > reading the DRYML page I am not able to where the performance is lost in > the page. > > My question is this: *Can I use a ruby call profiler to discover which > DRYML tags are eating the CPU? * > > Do you have any suggestions? > > -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/hobousers. For more options, visit https://groups.google.com/d/optout.
