Performance problem

[Michael Latta]

I have a form that is performing very badly. The form has a large number of sub-form records being displayed: 50 or so.

The log shows 200-300 ms for the horizontal header, and about 100 ms for each record. The attribute partials account for about 42 ms of the 100 per record.

When I attempt to measure the code executed by the header template it is more like 1-2 ms for the calls like getting the config or testing columns for hidden.

The total query time reported is < 20 ms and the view time reported is < 10 ms

The records have a large number of association columns with form_ui :select.

This is on the VHO fork as a gem under 1.9.2p180.

Michael

[Michael Latta]

I found at least some of it. There are 5 associations formatted as selects. There are a large number (5) of select associations per record and with 50 records each record spends about 20 ms generating options, sorting the collections and so on. There has to be a way to cache those options to save a lot of time.

Michael

> --
> You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" group.
> To post to this group, send email to actives...@googlegroups.com.
> To unsubscribe from this group, send email to activescaffol...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/activescaffold?hl=en.
>

[Sergio Cambra .:: entreCables S.L. ::.]

On Martes, 3 de Mayo de 2011 07:50:25 Michael Latta escribió:
> I found at least some of it. There are 5 associations formatted as
> selects. There are a large number (5) of select associations per record
> and with 50 records each record spends about 20 ms generating options,
> sorting the collections and so on. There has to be a way to cache those
> options to save a lot of time.

You can override options_for_association to cache options for each
association:
def options_for_association(association, include_all = false)
options_cache = include_all ? @options_cache_all||={} : @options_cache||={}
options_cache[association.name] ||= super
end

It will work only if options must be the same for all records in all subforms.

>
> Michael
>
> On May 2, 2011, at 11:31 PM, Michael Latta wrote:
> > I have a form that is performing very badly. The form has a large number
> > of sub-form records being displayed: 50 or so.
> >
> > The log shows 200-300 ms for the horizontal header, and about 100 ms for
> > each record. The attribute partials account for about 42 ms of the 100
> > per record.
> >
> > When I attempt to measure the code executed by the header template it is
> > more like 1-2 ms for the calls like getting the config or testing
> > columns for hidden.
> >
> > The total query time reported is < 20 ms and the view time reported is <
> > 10 ms
> >
> > The records have a large number of association columns with form_ui
> > :select.
> >
> > This is on the VHO fork as a gem under 1.9.2p180.
> >
> > Michael

--
Sergio Cambra .:: entreCables S.L. ::.
Mariana Pineda 23, 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) ser...@entrecables.com

[Michael Latta]

Thanks for the pointer. It looks like that will save about 1 second on my laptop (more on the small server we are using for testing). Disabling autoload of classes saved 2.5 seconds of the 5 (not a factor on the test box).

Michael

[Ed W]

Also have a look at some of the ideas in my "performance" branch on
github. I found a bunch of time was due to the GC being called
frequently. This in turn is due to large amounts of concatenations and
temp variables created in freq called functions.

Even small decreases in the size of created partials and implicitly
number of concat operations can work wonders.

I need to work on other projects for the next fair while, but I think
there is a lot of performance to be gained by a slightly invasive change
to alter how we generate our output. Basically moving stuff up the tree
and as far as possible even to compile time. I did discuss a bunch of
ideas with Sergio, but we didn't reach an agreement because he is a
little more conservative than me about removing per call customisation
options... :-) However, I think it's solveable

Good luck

Ed W

[Michael Latta]

I removed about 30% by caching the options for the high number of belongs to associations in that table, combined with the high number of records.

I would think however that a general caching solution could be implemented since in most cases the options are not unique to the record. I do have cases where they are unique to the record based on security and other restrictions, so per-record options needs to remain an possibility.

Given that I am using the Rails 3 fork I can not use your branch directly, but will look at it for ideas.

Michael