crossjoin/Browscap is worth a look

[kenjis]

I've found another browscap parser: https://github.com/crossjoin/Browscap
It is faster and less memory usage than browscap-php. Worth a look.

My benchmark at PHP 5.5.11 (Linux 32bit)

browscap-php:       time 0.13754391670227,    memory 8388608
crossjoin-browscap: time 0.00087594985961914, memory 524288

[WanWizard]

whoa, that looks very promissing!

[emlynwest]

@sagikazarmark Ping ;)

[sagikazarmark]

I am on it. My concerns so far:

• Since it is not an "official" package, support is a question
• Seems to me a bit over-abstracted
• Seems like it does not support returning an array
• No stable release yet

Will look into it. contact with the author... But If these concerns get void, then I will change the implementation.

[kenjis]

Seems like it does not support returning an array

It returns single dimension stdClass. So it is easy to convert array, just cast with (array).

then I will change the implementation.

It is better we could switch implementations by config.

[sagikazarmark]

I would say we should choose one or implement an adapter pattern. It does not make much sense to have to similar browscap solutions.

I am also thinking about letting the user use the get_browser if he wants. That could also be implemented as an adapter. However this is an agent package, so should not be overcomplicated.

I am going to look at DI for the next few days, see if I can come up with an automatic interface resolution.

[kenjis]

I'm sorry. My benchmark in #1 (comment) was misleading.
That was a case (UserAgent string) which crossjoin/Browscap processes very fast.
Another UserAgent string may result in different process time.

Now I'm not sure that crossjoin/Browscap is faster than browscap-php over all. Results depend on platforms and UserAgent strings.

But I'm still sure crossjoin/Browscap uses considerably less memory than browscap-php.

[sagikazarmark]

No problem, I am going to write some benchmarks as well.

[kenjis]

I've updated my benchmarking. This is more realistic scenario for me.

My conclusion is crossjoin-browscap is not faster than browscap-php over all, but considerably less memory usage. get_browser() is too slow to use.

Results for parsing 100 user agent strings:

{
  "get_browser":       {"time":47.569047927856, "memory":524288},
  "browscap-php":      {"time":1.1221010684967, "memory":13631488},
  "crossjoin-browscap":{"time":3.0749452114105, "memory":1572864}
}

100 user agent strings (from my real logfile):
https://github.com/kenjis/user-agent-parser-benchmarks/blob/master/data/ua-list-100-sample01.txt

Environment:

  CentOS 6.5 (64bit) on VirtualBox (Host: MBA OS X Yosemite)
  PHP 5.5.18
    Zend OPcache v7.0.4-dev
    Xdebug v2.2.5
  Apache 2.2.15

I don't know why but on Mac OS X it seems crossjoin-browscap is a bit faster than browscap-php.

[sagikazarmark]

Make sure to disable auto updating. That is a prerformance gain as well.

[WanWizard]

Would it be an option to make it driver based, so you can choose which backend you want?

[sagikazarmark]

That's what I am thinking about, however having a driver for nearly the same solution seems to be an overkill.

[kenjis]

@sagikazarmark Thank you for your comment.

I did not disable auto updating, so I disabled it.
But my benchmark results did not change a lot. Because my benchmark uses only one object to parse 100 UserAgent strings.

And I noticed crossjoin\Browscap put cache files on system tmp (= RAM disk). So I changed it to local HDD, because browscap-php's cache was in local HDD.

The new results:

parser	time	peak memory
get_browser()	46.237493991852	524288
browscap-php	0.95736503601074	13369344
crossjoin\Browscap	2.8503410816193	1310720

[kenjis]

I hope a mechanism to switch parser easily. Driver or adapter pattern?
So users could write for their own if they need.

[sagikazarmark]

Yeah, when benchmarking softwares and not only parts of code you have to make sure that it doesn't "cheat" (for exampl uses a faster cache). ;-)

Regarding the number of iterations: I usually set it to a higher number (1000-10000), but it probably doesn't matter in this case.

Adapter pattern is probably the most fitting solution. Which will play nicely with the new dependency injector which will make it possible to resolve instances for interface/abstract class typehinted constructors.

Could you please share your benchmark code with us, so we can play with it a bit?

[sagikazarmark]

Regarding the adapter switch: the fact that it is possible to switch adapters does not mean it has any sense to write an own. Just my 2 cents.