Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
File cache backend
« on May 23rd, 2013, 04:27 PM »
Just a slightly crazy thought. The file cache serializes content and unserializes it later on.

I wonder if it is safe and better performing to json_encode it instead. Only if native json_encode is available, of course. I did a test a while ago and for the data set I had (large arrays, of arrays of numbers), unserialize was significantly slower than json_decode for my data.

We don't serialize resources or object instances in the base software (there is no reason for us to do so), so from my perspective I see no real reason why we can't do that. If native functions are not available, then we use serialize as normal.

Thoughts?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: File cache backend
« Reply #1, on May 23rd, 2013, 08:23 PM »
I like the idea of more optimized if available but still works if not for what ever reason.
Thank you,
Boko

Nao

  • Dadman with a boy
  • Posts: 16,061
Re: File cache backend
« Reply #2, on May 23rd, 2013, 08:29 PM »
Odd. From my testing months ago, json was slower than serializing. I didn't insist.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: File cache backend
« Reply #3, on May 23rd, 2013, 08:33 PM »
Really? Even native functions?

And, really, I'm not particularly interested in json_encode vs serialize, because unless it's vastly out of whack, it's irrelevant - it's write once read many. The debate is json_decode vs unserialize where it really matters.

* Arantor might try and benchmark that later.

Nao

  • Dadman with a boy
  • Posts: 16,061
Re: File cache backend
« Reply #4, on May 23rd, 2013, 10:37 PM »
Quote from Arantor on May 23rd, 2013, 08:33 PM
Really? Even native functions?
Yeah. Then again, it's complicated... It's something like, json_encode is faster than serialize, but json_decode is slower than unserialize, or the other way around... Plus, both systems behave differently depending on the complexity of the string.
All in all, I'd decided not to look further into it, but considering that we don't use caching that much, I don't think there would be much of an improvement, whether you want to use serialize or json_encode. After all, I think that most of the caching process is spent on the file system manipulation, rather than data manipulation itself.
Quote
And, really, I'm not particularly interested in json_encode vs serialize, because unless it's vastly out of whack, it's irrelevant - it's write once read many.
I'm not so sure about it...
I mean, there are many cases where the delay is very short, to avoid being too much behind the real data, so I think that at least half of the time, caching will fail for something, because it's not accessed that much.
I don't have any data to prove my point, though...
Quote
* Arantor might try and benchmark that later.
Good idea.

$a = microtime(true); for ($i=0; $i<1000; $i++) { my code... } echo " ", microtime(true)-$a;
$a = microtime(true); for ($i=0; $i<1000; $i++) { my alt code... } echo " ", microtime(true)-$a;


I love how easy it is to benchmark stuff in PHP... Eh, I can even write the above in just a few seconds, I've done it so many times already... :P

Sorry for being so slow on work these days, BTW... I'll try to upload the latest commits you did, though.