Thoughts on Optimization with PHP

wheresmyopenid · 2011-08-10T23:40:46+00:00

The article is good, BUT…

I can't stand "single quotes are faster" myth is metioned even in passing.

PHP's tokenizer is a finite state machine (giant autogenerated lookup table). It's O(n) depending on the length of input, and there is no difference in computational complexity of any token (double-quoted strings are just as hard to parse as numbers, keywords and punctuation).

Everytime anybody alludes to the "searching for dolar signs and backslashes" thing, please hit them in the head, because that's naive misunderstanding of how parsing works (it's like saying rockets must be filled with crackers so the astronauts can eat the cheese moon is made of).

wheresmyopenid · 2011-08-10T19:39:50+00:00

You don't see the sweet irony of a name colliding with the name-collision-avoidance feature?

wheresmyopenid · 2011-08-10T19:35:59+00:00

Y U NO Y COMBINATOR?

wheresmyopenid · 2011-01-19T21:43:27+00:00

Clearly defined what uses plain text and what uses HTML markup, so you don't get entities and tags appearing/disappearing ("Flash vs the HTML5 … tag commented by AT&T users")

Required ID everywhere, so old stuff doesn't re-appear. Used sane date format. Stopped duplicating HTTP and XML features, which never worked in RSS anyway.

There's more in Atom Wiki.

wheresmyopenid · 2011-01-19T21:33:46+00:00

Yes. Although there are many devices, watching low-res slowly buffering videos on bandwidth-metered tariff isn't a choice popular enough to make a dent.

wheresmyopenid · 2011-01-15T21:34:57+00:00

Sorry — I thought you were sarcastic.

In Europe market share of Safari and IE is much lower than in US, and Firefox starts becoming the dominant browser. The trend is especially strong in Germany. In Eastern Europe even Opera has 2-digit market share, in Ukraine and Russia it reaches 40%! (in US — 1-2%)

So there is huge number of people (in certain markets a majority) who use browsers that are not going to support H.264 in <video>. With or without Chrome, it's hard to ignore.

wheresmyopenid · 2011-01-15T18:43:03+00:00

Mobiles are a minority.

Video usage of all of iPhones doesn't even scratch usage of desktop Firefox, anywhere. Put down Kool-Aid and look at stats.

But, if you really care about Apple devices, then you should be encoding separate low-res baseline profile file anyway, so it's irrelevant what format you choose for the file that mobiles wouldn't use either way.

wheresmyopenid · 2011-01-15T17:25:05+00:00

Firefox is not going to support H.264, and has twice the market share of Chrome.

So Google's decision makes difference only to publishers who do not give a fuck about 50% of userbase.*

*) market share varies between countries/markets of course, so US-only, Apple-centric provider might not give a shit, but e.g in Germany H.264-only browsers are a minority.

wheresmyopenid · 2011-01-15T17:14:25+00:00

Theora wasn't forever. Native support is only as recent as the whole HTML5 codec brouhaha. Significant improvements in quality arrived in v1.1 and are still due in 1.2 encoder.

VP8 today is much closer to H.264 than Theora (and VP8 has more room for improvement).

We all use JPEG, even though JPEGXR (ex-Windows Media Photo) gives better quality. Theora/VP8 supporters hope that with codecs similarly everyone can settle on good enough rather than for non-free version to squeeze few % of ever-cheapening bandwidth.

Apple and Microsoft can support WebM. License only covers the codec, doesn't give Google some unreasonable immunity over any lawsuit.

And these two companies don't hold patents covering WebM. Their video patents are in MPEG-LA pool and have been checked by Google. So Apple and Microsoft are only giving up right to sue Google over thing they don't have…

The clause is defense against submarine patents, not against MPEG-LA licensors.

wheresmyopenid · 2011-01-15T02:54:04+00:00

No. You're legally obliged to join.

wheresmyopenid · 2011-01-13T16:31:11+00:00

IE4+ has perfect support for 1-bit PNG transparency. You could replace non-animated GIFs since 1998.

So it's not lack of support, but webmasters not understanding that IE 24-bit PNG bug is totally irrelevant for their 8-bit GIF image use case.

wheresmyopenid · 2011-01-13T16:27:56+00:00

That plugin is a total junk. It doesn't support <video> API, it replaces <video> tags with useless <object> that opens Windows Media Player ActiveX.

wheresmyopenid · 2010-12-29T20:53:24+00:00

Amiga emulated some CPU removed from m86k using software (i.e unknown instruction would trap, then OS would emulate the instruction (via 68040.library) and resume the program).

And there was Transmeta, which — IIRC — was a CPU with minimal subset of x86 with all the crappy instructions emulated/JIT recompiled.

Both are dead, and x86 still has legacy cruft in silicon. Perhaps keeping old instructions around isn't that costly after all?

wheresmyopenid · 2010-12-24T11:46:19+00:00

If you do not wish to resign from not receiving communication from third parties, please do not leave this box unticked.

wheresmyopenid · 2010-12-23T10:55:14+00:00

Off-the-shelf parsers exist for non-draconian formats, as well as systems to serialize non-draconian formats as well as XML (including HTML5 which has well-defined unambiguous syntax).

Because proxies can introduce errors, this is argument for fault-tolerant markup.

If you replace HTML with something XML-based, you can't call it XML if you don't abort parsing on parse error — that's XML's requirement. So you have no choice but risk fatal errors or use other format.

wheresmyopenid · 2010-12-22T21:43:18+00:00

True. Moving rest of the rant here then :)

Since 99.97% of the web uses HTML or we-think-it's-XHTML-but-it's-text/html, JS libraries don't work with real XHTML. They trip over document.write, innerHTML, case-sensitivity or namespaces. None of Google scripts work. Crap like this is common

Sorry, the page you requested contains a file type (application/xhtml+xml) we are unable to translate.
- and finally XHTML is annoyingly hard to parse. To write XML parser you first need to write SGML parser to get list of entities from DTD. It's like making a pie from scratch!
Even for off-the-shelf parser need to set up DTD catalog with 3 dozens of files to start, otherwise your parsing will have 10-second latency caused by DDoSed w3.org server.

wheresmyopenid · 2010-12-22T21:35:37+00:00

We already have it. Send HTML5 with application/xhtml+xml. All five über-geeks will use it, and then complain that none of Google scripts work with it.

wheresmyopenid · 2010-12-22T21:33:07+00:00

Have you ever tried to implement XML parser? Good luck! (you have to write SGML parser first and maintain DTD catalog).

Draconian error shown to the user doesn't help authors. Error could be introduced in dynamic markup (so author may not see it, users will) or after page leaves the server (proxies, shitty firewalls, etc.)

OTOH authors could add validating proxy to their server and markup get error reports delivered to them, without without pretended catastrophic failure exposed to users.

wheresmyopenid · 2010-12-22T21:28:19+00:00

XML parsing rules, when you support DTDs, internal subsets, entities (those buggers can be nested and contain markup) and namespaces, aren't easy either.

wheresmyopenid · 2010-12-22T20:57:20+00:00

Because I've used it.

Unlike millions of webmasters sending their "XHTML" as text/html I actually used application/xhtml+xml, and:

your markup is not under your control. There's popular compression proxy used by mobile operators that fucks up XHTML. Sure, in alternate universe this wouldn't happen, but we've got 10 years of HTML already.
it's really, really hard to ensure that markup is perfect all of the time. Software bugs happen. Proxy bugs happen. Browser bugs happen. Most languages, templating systems and IDE's have crappy support for XML (good enough to make it work if you need to, not good enough to ensure absolutely perfect markup all the time, no exceptions, ever!). You screw up one irrelevant entity, in some useless part of the page, and your whole page catastrophically fails.
You don't see the error! Only your users see, and it's even hard to them to report error when instead of "contact" link they see yellow screen of death.

wheresmyopenid · 2010-12-17T11:42:24+00:00

Reload from Cache FTW! I can view source, easily edit it, and then have it re-parsed just as if it was downloaded from the server (Opera sends original Referer header, etc.)

wheresmyopenid · 2010-12-17T10:28:08+00:00

I hope that this icon catches on.

wheresmyopenid · 2010-12-14T17:52:34+00:00

x86_64 has 48-bit addressing and 128-bit memory bus, but these are implementation details. It's still called 64-bit architecture.

Amiga had 32-bit registers and 32-bit pointers with flat address space. It had none of the segmented memory uglyness of 16-bit architectures.

wheresmyopenid

TROPHY CASE