paginate_links runs number_format_i18n for the entire range of pages

[johnpbloch]

It does this regardless of whether they are actually used.

On large sites this adds significant overhead when paginate_links() is used on the front page.

[johnpbloch]

Unit Test

[johnpbloch]

Patch

[johnpbloch]

This is a bad ticket.

To reproduce:

Use paginate_links in such a way that it will not use the whole range of pages passed to it.

Expected behavior: it will run number_format_i18n() only when the number is actually used.

Actual behavior: it runs number_format_i18n() for all numbers regardless of whether they're used.

[johnpbloch]

Slightly better test

[johnpbloch]

I've added a failing test and a potential solution.

[johnpbloch]

Unified patch

[johnpbloch]

As a matter of curiosity, Nacin had wondered what performance looks like before and after applying the patch. Here are two cachegrind profiles, one from before and one from after:

​Before

​After

This was on an installation with just north of 22,000 posts in the database. At that size, this defect added .1 second to the request and number_format_i18n() had a total self cost of 6.67% and a total inclusive cost of 11.69%. This is entirely in keeping with the data I saw when I first discovered the issue on a database with 110,000+ posts in the database.

[johnbillion]

In 27523:

Improve paginate_links() performance by not calling number_format_i18n() unnecessarily. Fixes #25735 with tests. Props johnpbloch.