Merge standard and full version of the file.

[quentin389]

In my tests https://github.com/quentin389/ua-speed-tests I only see a very small performance difference between using php_browscap.ini and full_php_browscap.ini. Perhaps there is no reason to keep both versions if the time differences are that small?

Browscap execution time can be separated into two most important parts:

• loading the data into memory
• executing regular expressions

The time to execute regular expressions doesn't change at all between those two file versions, because full version only adds new properties, not new matches.

The file size and the data size increases in the full version but not that much. Hence only small execution time differences.

[asgrim]

From what I can see in your data, the "lite" still significantly faster? Would you recommend keeping the "lite" version then? As that I think is the highest maintenance - the tool I've made can very easily generate full/standard differences, but at present we have no "lite" flag (so essentially, that format is currently "dropped").

[quentin389]

Yes, the light version is super-fast compared to normal/full, although right now when I look at the files I wonder why is that... The file is merely 1/2 of the size of the normal one but it's more than 5 times faster... that's suspicious.

The http://tempdownloads.browserscap.com/ site says "A smaller version of php_browscap.ini file containing major browsers & search engines. This file is adequate for most websites." so I think a lot of people may be using that file. But that's just a guess.

So I don't think you can justify dropping support for that file.

[quentin389]

Is the lite version so fast because it's buggy? It's possible, see: #8

That would explain the speed difference.

I think that should be investigated further.

[asgrim]

The counter argument to doing this is that the overhead to generate the full (versus the normal) version is negligible... It would probably be more effort to remove it than leave it in ;)

[mimmi20]

Is something thinking about resolving this issue? See #248.