3 ms·

Not a knock against the people who created metacpan, but it is interesting how much faster search.cpan.org is than metacpan.org when displaying basically identi

Not a knock against the people who created metacpan, but it is interesting how much faster search.cpan.org is than metacpan.org when displaying basically identical information on module pages. The page load time is consistently about 5 to 10 times faster on search.cpan.org on the first load of a page, though subsequent loads are faster on metacpan, so they must have some caching in front.

kbenson 8y ago
My experience was always the complete opposite, but I've avoided cpan.org in lieu of metacpan for years now because metacpan has a better experience overall. It likely changed over the years as the majority of Perl programmers switched to metacpan, which seems to go back around 7 years at least. According to alexa,com there's been a large shift in the last year or so, and metacpan.org is serving something like 3-4 times the amount of traffic. Additionally, each page is displaying much more info (such as dependencies, cpantesters platform testing statistics, etc).
combatentropy 8y ago
The new site's search results are noticeably slower. On search.cpan.org, searching for "cgi" took 90 milliseconds, whereas the new site takes 1.25 seconds. I tried several times.
- kbenson 8y ago
  They likely don't search the entirely same set of data (that is, cpan's search is likely a subset of metacpan's search). Also, metacpan groups results by package, which cpan returns individual modules (that is, you might have multiple results, one for each module in a package that matches in some manner). Page load speed isn't everything, and the the very quick search suggestions from the metacpan search that on a regular basis get me exactly what I want without a full search page load more than make up for it for me.
- rurban 8y ago
  Because the metacpan search is written in java and does not use a fast search engine, like xapian, which does have nice perl5 bindings. Also Elasticsearch uses 10x more RAM.

kbenson 8y ago

My experience was always the complete opposite, but I've avoided cpan.org in lieu of metacpan for years now because metacpan has a better experience overall. It likely changed over the years as the majority of Perl programmers switched to metacpan, which seems to go back around 7 years at least. According to alexa,com there's been a large shift in the last year or so, and metacpan.org is serving something like 3-4 times the amount of traffic. Additionally, each page is displaying much more info (such as dependencies, cpantesters platform testing statistics, etc).

combatentropy 8y ago

The new site's search results are noticeably slower. On search.cpan.org, searching for "cgi" took 90 milliseconds, whereas the new site takes 1.25 seconds. I tried several times.

kbenson 8y ago
They likely don't search the entirely same set of data (that is, cpan's search is likely a subset of metacpan's search). Also, metacpan groups results by package, which cpan returns individual modules (that is, you might have multiple results, one for each module in a package that matches in some manner). Page load speed isn't everything, and the the very quick search suggestions from the metacpan search that on a regular basis get me exactly what I want without a full search page load more than make up for it for me.
rurban 8y ago
Because the metacpan search is written in java and does not use a fast search engine, like xapian, which does have nice perl5 bindings. Also Elasticsearch uses 10x more RAM.