Two things:
Getting the counter should be a 1+1 operation, not 1+n. If its not, then this
could be a place for improvement.
I find the counters to be almost useless in the final code: they are good in
development to show that the relationships work properly. I suspect that this
is the case in most applications (although I have no supporting data), which
means that optimizing it should be a lower priority.
My 2 cents worth.
Henry
On September 30, 2010 07:24:12 am Tiago Franco wrote:
> Hi,
>
> To solve the n+1 problem I've added counter_cache to most of the 1-N
> relations. This has a significant impact, mainly because cards were
> showing a lot of counters.
>
> Does it make sense to consider the introduction of counter_cache on Hobo
> fields? Probably by adding them in the migration generator?
>
> TF
>
> On 09/30/2010 02:58 AM, kevinpfromnm wrote:
> > The n+1 query problem is pretty prevalent if you don't use includes on
> > your parent find. Any place it's becoming a hit, you should add
> > an :include => :child or [:child1, :child2] or if you need
> > grandchildren, { :child1 => [:grandchild1, gc2], :child2 => [] } See
> > standard rails active_record find for exact details on syntax. That's
> > going to be the majority from hobo, any extra queries will (usually)
> > be from custom view code and permissions.
> >
> > It's unfortunately quite difficult to automatically optimize (but
> > maybe there's something there by using children from viewhints or when
> > compiling a page, maybe figure out what associations are needed and
> > add those to a include list used by hobo_* in the controller?).
> > Anyway, there's no magic bullet for optimizing database queries, just
> > gotta poke and see what's actually getting called and how you can
> > minimize it.
> >
> > As far as I know, there is no performance difference between fixed and
> > generated. Both are compiled and only difference should be from any
> > customizations on your part.
> >
> > Last question, don't know as I haven't got any public facing apps.
> >
> > On Sep 29, 6:46 pm, Scorpio<[email protected]> wrote:
> >> Hi. I'm beginning to understand now how Hobo works (at long last) and
> >> its no longer a "just make it work" thing for me. I've begun thinking
> >> about some optimization. The first thing that came to mind were
> >> database queries. I've noticed that whenever I call a page with say a
> >> lot of children i get a lot of queries. I've also noticed that there
> >> are a lot of queries in general. Is that normal hobo behavior ? Can it
> >> be optimized in some way ? (sorry for asking a seemingly dumb question
> >> but I figure since Hobo has so much "magic" inside it might just have
> >> a solution for it)
> >>
> >> The second issue are the generations of the un-customized pages that
> >> Hobo makes. I've been wondering whats better. fixed show.dryml etc or
> >> the generated ones (load- and performance-wise).
> >>
> >> Last but not least. How does the Hobo auto generation and a Hobo app
> >> in general work with search engines when it comes to positioning the
> >> website? are there any issues I need to know or any tedious tasks I
> >> need to undertake to make it work? (I've made Hobo add metadata to a
> >> page HTML-style)
> >>
> >> Thanks in advance.
--
Henry Baragar
Instantiated Software
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
