Issue: Locale-index is slow

[megasnort]

A couple of months ago I modified the locale-page so the export was logical, some extra info was shown (edited_on), and sorting worked better.

Downside: especially with bigger datasets the index-page is even slower. This is because the (4!) datagrids it uses do most of the work (sorting ...) in a very inefficient way.

A first quick fix could be to, by default select only 'frontend' in the filter, and not the complete locale.

But, performance could be won in different ways:

• Is the field 'edited on' necessary?
• Do there really have to be four datagrids? I think removing threee, and adding an extra column 'type' would make it possible to make the biggest performance win.
• ...

[WouterSioen]

I would leave the edited on field there. I don't think this is the real bottleneck (have you profiled it?). It's useful for when you want to change something you've recently edited, or if you want to export the stuff you recently edited in one language, to import later in another one.

I'd really suggest to profile this page. In most cases, slow pages are due to slow queries and could possibly be improved by adding an index. PHP actions are in most cases not the bottleneck.

[bart-webleads]

Queries are not slow. Loading data in grid is slow...

Maybe add a limit filter?

[glenncoppens]

It's like Bart says, queries aren't slow. Probably the method modifiers are (and I guess especially the date modifier).

I created this gist to use the Intl extension as a custom modifier. It was the result of this thread/issue.

Maybe it helps :)

[WouterSioen]

Has somebody profiled this? It's the only way to really know the bottlenecks.

[megasnort]

I'll give Blackfire a spin.

[WouterSioen]

Great!

Op dinsdag 17 maart 2015 heeft Stef Bastiaansen notifications@github.com het volgende geschreven:

I'll give Blackfire a spin.

— Reply to this email directly or view it on GitHub https://github.com/forkcms/forkcms/issues/1131#issuecomment-82300320.

[megasnort]

The getTimeAgo-modifier is indeed the culprit. Every times it is executed the locale-file (en.php) is parsed again. The bigger the locale, the bigger the locale-file and the bigger the number of times it is parsed. It slows down with a power of two.

I created a function getDateTime (instead of getTimeAgo) in DataGridFunctions.php, which does nothing more then

return date('Y-m-d H:i:s', $timestamp);

Which gives the following results in blackfire

To compare, the original code gives these results

Long story short, do you think it is acceptable to not use the date-settings and thus the locale-file (which are used by the other date-modifiers) and just show the plain date, like so:

Note: You can actually leave out any the modifier, since the dates are stored as a DateTime. This gives almost the same results.

[WouterSioen]

Why is the locale file parsed every time? Isn't it easier to use the cached locale?

Op woensdag 18 maart 2015 heeft Stef Bastiaansen notifications@github.com het volgende geschreven:

The getTimeAgo-modifier is indeed the culprit. Every times it is executed the locale-file (en.php) is parsed again. The bigger the locale, the bigger the locale-file and the bigger the number of times it is parsed. It slows down with a power of two.

I created a function getDateTime (instead of getTimeAgo) in DataGridFunctions.php, which does nothing more then

return date('Y-m-d H:i:s', $timestamp);

Which gives the following results in blackfire

[image: withoutlocalestuff] https://cloud.githubusercontent.com/assets/736827/6708272/02894f20-cd6f-11e4-9076-57e8dd671c64.png

To compare, the original code gives these results

[image: withlocalestuff] https://cloud.githubusercontent.com/assets/736827/6708259/de59448e-cd6e-11e4-8165-71fe1d1d10fc.png

Long story short, do you think it is acceptable to not use the date-settings and thus the locale-file (which are used by the other date-modifiers) and just show the plain date, like so:

[image: schermafbeelding 2015-03-18 om 13 07 34] https://cloud.githubusercontent.com/assets/736827/6708360/d2d1303a-cd6f-11e4-9bb5-d86f9ccf5a7d.png

— Reply to this email directly or view it on GitHub https://github.com/forkcms/forkcms/issues/1131#issuecomment-82939778.

[megasnort]

Found it. In the Spoonlibrary, in the getTimeAgo I replaced this line

require 'spoon/locale/data/' . $language . '.php';

with

require_once 'spoon/locale/data/' . $language . '.php';

Which gives these results.

I did a pull request in the Spoon-library repo, I don't know if someone is still checking that?

[WouterSioen]

You should do the pull request to https://github.com/forkcms/library, this is the forked version we use.

[WouterSioen]

I've updated spoon in the master branch, this will be available in the next release.