PHP, the universe and all the rest Comments

hartmut: PHPreboot braindump

nospam@example.com (hartmut) — Thu, 13 Oct 2011 09:13:17 +0200

There is nothing wrong with it by itself, it is just very uncommon and i don't remember having seen any PHP code that uses it in ages ...

... and so it was not a clever choice to use it in a "see, looks like PHP" example IMHO

Guy: PHPreboot braindump

nospam@example.com (Guy) — Wed, 12 Oct 2011 19:33:37 +0200

I use elseif whenever appropriate (v.s. "else if"). You seem to suggesting there is something wrong with it.

hartmut: PHPreboot braindump

nospam@example.com (hartmut) — Wed, 12 Oct 2011 14:08:27 +0200

Again, very very old news

it came up in two different German news sources a few days ago, thus the reaction

The author has already abandoned it ...

would be nice if that was actually stated on the project page

also i would have commented on the project page instead of this blog if only it had any sort of useful feedback mechanism ...

Btw, native XML support is already possible in PHP

ok, we seem to have different definitions of "native XML" then ...

hartmut: PHPreboot braindump

nospam@example.com (hartmut) — Wed, 12 Oct 2011 14:04:48 +0200

"The name 'PHP' must not be used to endorse or promote products derived from this software..."

Fuzzy area, it's not really using the name, just the letters ...

PS: yes, not so clever theme choice after all ... changed ...

mario: PHPreboot braindump

nospam@example.com (mario) — Tue, 11 Oct 2011 22:40:28 +0200

Again, very very old news. The author has already abandoned it, but what phpreboot had going for it was that it was actually working.

Btw, native XML support is already possible in PHP: https://github.com/facebook/xhp - The not quite insignificant potential benefit being no more need for XSS escaping.

Steve: PHPreboot braindump

nospam@example.com (Steve) — Tue, 11 Oct 2011 15:15:58 +0200

"so why should it have the letters PHP in its name at all?"

Moreover, isn't that a blatant breach of the PHP license?

P.S. this page is remarkably difficult to read - pale grey text on white is just nuts.

hartmut: Why go with O(n) if you can have O(n²)?

nospam@example.com (hartmut) — Fri, 04 Mar 2011 10:04:19 +0100

Any 'Solution' that scales by n^2 while an equivalent solution scales linearly with growing n is a bad idea. Period.

If you're using an ORM that can not deal with large result sets then the ORM is conceptually broken and adding LIMITs is just a workaround, not a solution.

And if you really have to use such a workaround then please use a sensible chunk size. Something in the range of 10K maybe ... but *definitely* not just 100 ...

gggeek: Why go with O(n) if you can have O(n²)?

nospam@example.com (gggeek) — Fri, 04 Mar 2011 09:29:06 +0100

I concur with Dan. Not really being interested in php memory leaks (that should be fixed by the developer), you still have to take into account the memory used for fetching the data from the db. If the developer hand-codes his queries, he can send a single select and fetch little by little. Unfortunately if there is an orm involved, it is most likely that this piecewise fetching is not supported, but sending many paginated queries is...

hartmut: Why go with O(n) if you can have O(n²)?

nospam@example.com (hartmut) — Thu, 03 Mar 2011 19:09:13 +0100

I'm not ranting against pagination in a user frontend, that usually makes perfect sense as the typical user would only check out the first hand full of pages anyway.

What i'm talking about is an export script that creates the CSV export file in one go, just with multiple queries instead of a single one.

So any potential PHP side memory leak issues would hit you anyway while the script chews its way through the ~40K result rows; the only exception being the MySQL result set buffer which would indeed be smaller when using good old ext/mysql or mysqli_store_result() with the newer ext/mysqli (while mysqli_use_result() would only internally store one result row at a time anyway).

And regarding your multitasking/resource usage argument: any advantage of that in this "we need to show all data anyway" context would quickly be eaten away due to the O(n^2) nature of the approach, so that twice the amount of data would increase the database load four times while with a single query things would grow on a linear basis (assuming that the query itself scales linearly).

In this special case you'd also additionally have to count in that it does a GROUP BY and has "Using temporary; Using filesort" in it's EXPLAIN plan, so the LIMIT would save next to nothing in database resources while the pseudo-pagination causes the query to be run 400 times instead of just once ... and if we ever double the number of contacts in our database to 80K it would be run 1600 times then ... epic fail ...

Dan: Why go with O(n) if you can have O(n²)?

nospam@example.com (Dan) — Thu, 03 Mar 2011 17:23:24 +0100

Thought I'd share a bit since I've done this sort of thing myself. I don't believe you're giving the tradeoffs the proper attention in this case.

One being that if you are dealing with a large amount of rows and columns, memory consumption is a major barrier you start running into right away. Mix in how easy it is to introduce memory leaks with php's object model, and you have a recipe for disaster. I've found that people are much more tolerant if they have to wait a bit longer for something than not getting it at all (because you're script died from out of memory). If you use the paginate model, you have more fine-grained control over the entire process and can free up memory every pagination run.

The other trade off in this case is that if the server is multi-tasking, you are stealing a lot of i/o (mysql) in one fell swoop, then following up with a huge amount of cpu/memory. If you paginate, you switch from modest i/o (mysql) to modest cpu, then modest i/o, modest cpu (and so on), so you don't have to flat out deny other pending work.

hartmut: Why go with O(n) if you can have O(n²)?

nospam@example.com (hartmut) — Thu, 03 Mar 2011 14:06:47 +0100

No, as the query is spanning several tables (person, address, country, ...)

Daniël van Eeden: Why go with O(n) if you can have O(n²)?

nospam@example.com (Daniël van Eeden) — Thu, 03 Mar 2011 13:19:03 +0100

Could this bennefit from using the HANDLER statement?

mysql> SELECT * FROM test001;
+----+---------+
| id | name |
+----+---------+
| 1 | test 01 |
| 2 | test 02 |
| 3 | test 03 |
| 4 | test 04 |
| 5 | test 04 |
| 6 | test 05 |
| 7 | test 06 |
+----+---------+
7 rows in set (0.00 sec)

mysql> HANDLER test001 OPEN;
Query OK, 0 rows affected (0.00 sec)

mysql> HANDLER test001 READ `id` NEXT LIMIT 2;
+----+---------+
| id | name |
+----+---------+
| 1 | test 01 |
| 2 | test 02 |
+----+---------+
2 rows in set (0.00 sec)

mysql> HANDLER test001 READ `id` NEXT LIMIT 2;
+----+---------+
| id | name |
+----+---------+
| 3 | test 03 |
| 4 | test 04 |
+----+---------+
2 rows in set (0.00 sec)

mysql> HANDLER test001 CLOSE;
Query OK, 0 rows affected (0.00 sec)

mysql> HANDLER test001 OPEN;
Query OK, 0 rows affected (0.00 sec)

mysql> HANDLER test001 READ `id` NEXT LIMIT 2;
+----+---------+
| id | name |
+----+---------+
| 1 | test 01 |
| 2 | test 02 |
+----+---------+
2 rows in set (0.00 sec)

mysql> HANDLER test001 READ `id` NEXT LIMIT 2;
+----+---------+
| id | name |
+----+---------+
| 3 | test 03 |
| 4 | test 04 |
+----+---------+
2 rows in set (0.00 sec)

mysql> HANDLER test001 CLOSE;
Query OK, 0 rows affected (0.00 sec)

Status after HANDLER use:
mysql> SHOW STATUS LIKE 'Handler%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Handler_commit | 2 |
| Handler_delete | 0 |
| Handler_discover | 0 |
| Handler_prepare | 0 |
| Handler_read_first | 1 |
| Handler_read_key | 2 |
| Handler_read_last | 0 |
| Handler_read_next | 3 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 0 |
| Handler_rollback | 0 |
| Handler_savepoint | 0 |
| Handler_savepoint_rollback | 0 |
| Handler_update | 0 |
| Handler_write | 0 |
+----------------------------+-------+
16 rows in set (0.00 sec)

Status after select with limit (same rows read):
mysql> SHOW STATUS LIKE 'Handler%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Handler_commit | 2 |
| Handler_delete | 0 |
| Handler_discover | 0 |
| Handler_prepare | 0 |
| Handler_read_first | 2 |
| Handler_read_key | 4 |
| Handler_read_last | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 6 |
| Handler_rollback | 0 |
| Handler_savepoint | 0 |
| Handler_savepoint_rollback | 0 |
| Handler_update | 0 |
| Handler_write | 0 |
+----------------------------+-------+
16 rows in set (0.00 sec)

Artur Ejsmont: Is it really that hard ...? (or how i finally learned to hate CSS)

nospam@example.com (Artur Ejsmont) — Wed, 25 Aug 2010 10:31:55 +0200

heheeh so very true!

I had the same awakening few years ago when i though i would learn the proper way of using css instead of hacking this or that in nasty way ..... i got 2 books on css and guess what! they both said you need hacks to do the simplest 3 col layout. There is just no proper way to work with css as i see it.

I manage to do what i need but even now css is still annoying.

pinterface: Is it really that hard ...? (or how i finally learned to hate CSS)

nospam@example.com (pinterface) — Wed, 25 Aug 2010 04:13:25 +0200

On second thought, since it took me a bit of playing, I went ahead and threw up an example on my little corner of the 'net.
http://web.kepibu.org/tmp/css-test.html

pinterface: Is it really that hard ...? (or how i finally learned to hate CSS)

nospam@example.com (pinterface) — Wed, 25 Aug 2010 02:19:09 +0200

You don't have to resort to JavaScript, if you're willing to put up with a little extra markup. All you need is the oft-overlooked CSS tables (well, in browsers that support it--so not IE6 or IE7).
http://www.w3.org/TR/CSS2/tables.html
Unfortunately, your comment system insists on buggering some example code, so you'll just have to play around on your own.