Hacker News Reader

Hacker News

Comment by pearjuice | Hacker News Reader

Parent Full thread

pearjuice

I really hope they cleaned that mess up or I feel very sorry for all the developers at Facebook.

>ini_set('memory_limit', '100M'); // to be safe we are increasing the memory limit for search

>tpl_set('simple_orientation_first_login', $get_o); // unused right now

>// We special case the network not recognized error here, because affil_retval_msg is retarded.

>all those undocumented(?) random error codes

>mix between ternary operators and regular if/else statements with no logical choice between one or the other

>no auto loading whatsoever

Seeing as this is from 2007, there is hope.

View on HN

What's wrong with increasing the memory limit?

A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)

It would seem that Facebook has been able to scale. Perhaps this line of code worked for them in 2007, and they changed it only when it started to be a problem.

It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.

It is certainly not still there given that facebook doesn't run PHP any more. They wrote a compiler to translate a subset of PHP to C++, which they then compiled into a massive executable. The compiler is open source and called hiphop, and it does not implement the PHP memory limits.

By that logic, no one runs any programming languages, since they all get translated to x64 or other instruction sets.

That makes no sense at all. The function in question sets the memory limit for the PHP interpreter. A specific piece of software. Facebook does not use that specific piece of software.

Your comment was ambiguous then. It sounded like your logic was "they don't run PHP because they wrote their own implementation"... which is still running PHP. I think you meant to say they're not running the normal PHP interpreter, so that particular functional call might not be implemented (but it could be, still...).

Facebook still uses PHP bro...

They still write code in the language PHP. They do not run that code using PHP the software you download from php.net. The memory limits of the PHP interpreter from php.net are not relevant at all to facebook's current operations.

They don't do that anymore. Ask your Facebook friends, hphp has changed since then.

I know, I used past tense. But the initial hiphop work was when php memory limits stopped being relevant for them.

It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?

I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?

They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.

That sounds grossly ineffective.

Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.

Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum.

If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes.

Based on your comments in this thread you're out of your depth, man.

I still can't imagine not find an example of where anybody would want to return 500MB of results to PHP for processing.

I think Kiro meant 500, as in the HTTP status code, due to PHP running out of memory, not 500MB.

Guess what happens when a lot of people search.

Yes

That's an abnormally high memory limit for what should be a simple request.

Reply on news.ycombinator.com