Docs: Update performance metrics about pagy

[ddnexus]

it returns an object solely for pagination and doesn't pollute the returned object with extra functions. Perhaps this stems from performance things, not sure, I like it for it explicitness

Yes. Besides what you write, there is also the separation of concerns that helps keeping complexity at bay. Moreover the specific object for pagination allows also to be passed to any statically imported pagy function that uses the object, but it's not part of it. That makes even the extras really agnostic and very easy to call and overwrite right in your code.

Finally, the imported functions act like they are methods of the pagy object, but unlike object methods they are kind of "decentralized" in the parts of your app that use them and can override them more easily than what you would be able to do with object methods. A functional approach makes also the extension system a bit simpler IMO, but that could be done also the other way. On the con part... the imported function have to be prefixed with "pagy_" to minimize conflicts with the importing code.

The charts are still severely out of date

Maybe you don't like my note "While it's not up-to-date, you can expect roughly similar results with the latest versions, maybe a bit less dramatic in performance due to the multiple features added to pagy since v3 (e.g. customizable and translated aria-labels)." ... but that's good enough for now. As soon as I will have some time to play with it, I will redo the whole thing, which requires a lot of updates and work, but it will be also fun. For now, I prefer to keep this closed, because I don't sleep well with too many open issues 😄

[ddnexus]

I was thinking to drop it all instead, because it's probably not worth the effort anymore.

It was worth at the beginning, when people were asking "why the heck did you write a pagination gem when we already have the best... bla... bla..." not even knowing what they were talking about.

Recently I kept it in place because it's a nice ad showing numbers that I am emotionally attached to 😁...

I definitely should add a note referring to the versions compared. My estimate on how the current charts would appear is that - with all the added features - the diff would be a bit less massive, lowering the gap ~20% maybe. But you can't benchmark the added options and flexibility, so it's kind of worthless.

I will think about it. Thank you for your feedback.

[Earlopain]

They do take up quite a bit of real estate in the readme until you actually get to the important points on how to use this etc. It would still be interesting to see how these numbers are now in comparision nontheless, just for the sake of it.

For me at least, performance wasn't really a criteria when choosing. These metrics are nice, sure, but I'm not going to make major gains/losses by my choice of pagination gem. But yeah, I can see how that would have been a distinguishing feature in the beginning.

[ddnexus]

They do take up quite a bit of real estate in the readme

I reduced the real estate a bit and added a note for the versions. I think that's a little better than before. Thank you for pointing that out.

For me at least, performance wasn't really a criteria when choosing.

It all depends on the environment. If you use it in small traffic apps it's not a problem (for me it would just be a bit of disappointment, because I am kind of a performance freak), but if you use it in some high traffic app, you can consider that even if you save just a few millisec per object per request... that amounts to a huge waste of CPU and memory resource on the month. Why wasting anything if you can just organize the code in a better way and get the most for the least?

BTW, out of curiosity, what are the criteria that made you choose pagy?

[Earlopain]

BTW, out of curiosity, what are the criteria that made you choose pagy?

I like how it returns an object solely for pagination and doesn't polute the returned object with extra functions. Perhaps this stems from performance things, not sure, I like it for it explicitness. The docs here also look very nice in comparision to the other two.

The integrations with others gems/css frameworks seems cool, though I admit that I'm currently only using the AR one and not mich else

will_paginate is in maintenance mode by their own admission, so I'll just look for others by default.

---

On another note, could you reopen this? The charts are still severly out of date.