S>я скажу по секрету, что есть возможность писать и php+html в одном файле.
Когда я писал на РНР, то так и делал ))

S>А если по сути, и вернуться к вопросу темы, то фича с лапшой придумана чтобы заманить нубов легкостью создания первой в жизни страницы.
Ну или чтобы выбор был ) Кому от этого хуже будет? ))

Разобрался с одной из утечек. Оказывается тёк не php_mysql, а стандартная ф-ция strtotime(), результаты которой ложились в базу. Вот код для проверки:

for($i = 0; $i < 10000000; ++$i) strtotime("next Sunday", 0);

У меня утекает со скоростью примерно 500 КБ/сек, красота!

Здравствуйте, quwy, Вы писали:

Q>У меня утекает со скоростью примерно 500 КБ/сек, красота!

В реальном использовании это не будет проблемой, т.к. по завершении запроса вся память все-равно будет выброшена.

Здравствуйте, Lloyd, Вы писали:

Q>>У меня утекает со скоростью примерно 500 КБ/сек, красота!
L>В реальном использовании это не будет проблемой, т.к. по завершении запроса вся память все-равно будет выброшена.
У меня реальные условия и из-за этой фигни скрипт вылетает на хостинге.

Здравствуйте, quwy, Вы писали:

S>>и какая нужда заставила заняться гадостью?
Q>Деньги.

За последние несколько недель встречаю второго человека, который взялся за пхп ради денег. Куда мир катится?

Здравствуйте, quwy, Вы писали:

L>>В реальном использовании это не будет проблемой, т.к. по завершении запроса вся память все-равно будет выброшена.
Q>У меня реальные условия и из-за этой фигни скрипт вылетает на хостинге.

пациент: доктор, когда я делаю вот так, то мне больно
доктор: пациент, не делайте так

Здравствуйте, quwy, Вы писали:

q> q>> Только по вине быдлокодера. В php же память течет сама по себе.
q> AB>Даже если это так (в чем меня берут некоторые сомнения)
q> Это так. При массированной работе с mysql, убегает только в путь (все результаты выборки дестрою и соединения разрываю).

Пример для воспроизведения проблемы можно?

q> AB>это не является проблемой для веб-приложений — утекшая память освобождается со смертью обработчика.
q> Ну конечно, вообще проблема утечек памяти надумана, гигабайты ныне копейки стоят.

Я не об этом. Я о том, что много утечь за время жизни обработчика не сможет. К тому же, у php есть "родное" ограничение по потреблению памяти.

Здравствуйте, quwy, Вы писали:

q> У меня реальные условия и из-за этой фигни скрипт вылетает на хостинге.

У тебя версия php 5.2.8 или ранее (5.2.9 выпущена до 26 февраля 2009)?

Здравствуйте, Anton Batenev, Вы писали:


AB>Я не об этом. Я о том, что много утечь за время жизни обработчика не сможет. К тому же, у php есть "родное" ограничение по потреблению памяти.

Это не самое лучшее оправдание языку, которому недоступно управление памятью вручную. Представляешь срач, если бы java допускала утечку реальной памяти при вызове каких-либо методов, или вообще любая утечка, не связанная с неконтролируемым помещением ненужных объектов в живые коллекции(что, по сути, тупо косяк программиста, причем грубый, но легко ловимый)?

Здравствуйте, Eugeny__, Вы писали:

E> Это не самое лучшее оправдание языку, которому недоступно управление памятью вручную.

Почему же недоступно. Управление памятью доступно на уровне объектов самого языка.

E> Представляешь срач, если бы java допускала утечку реальной памяти при вызове каких-либо методов

А почему ты уверен, что JVM этого не может допустить?

Здравствуйте, Anton Batenev, Вы писали:

E>> Это не самое лучшее оправдание языку, которому недоступно управление памятью вручную.

AB>Почему же недоступно. Управление памятью доступно на уровне объектов самого языка.

E>> Представляешь срач, если бы java допускала утечку реальной памяти при вызове каких-либо методов

AB>А почему ты уверен, что JVM этого не может допустить?

Найди мне хоть один пруф. Допустить теоретически — может. Практически же прецедентов не было.

Здравствуйте, Anton Batenev, Вы писали:

E>> Представляешь срач, если бы java допускала утечку реальной памяти при вызове каких-либо методов
AB>А почему ты уверен, что JVM этого не может допустить?
В JVM как таковой утечки возможны из-за:
1) Случайно оставленных живых ссылок.
2) Нативного кода, оставляющего живые ссылки.
3) Багов в JVM.

Третий пункт тоже встречался в истории, но очень редко. Он считался критической багой.

Нативного кода в приложениях на Java не так много, так что пункт 2 не такой острый.

Здравствуйте, Anton Batenev, Вы писали:

q>> У меня реальные условия и из-за этой фигни скрипт вылетает на хостинге.
AB>У тебя версия php 5.2.8 или ранее (5.2.9 выпущена до 26 февраля 2009)?
5.2.14 от Jul 27 2010 10:47:27. И не у меня, а на хостинге, так что обновить (даже если будет на что) не выйдет.

Здравствуйте, quwy, Вы писали:

q> 5.2.14 от Jul 27 2010 10:47:27. И не у меня, а на хостинге, так что обновить (даже если будет на что) не выйдет.

Ага, нашел. В 5.3.3 баг уже не воспроизводится, а для старых версий заведены баги #46889 и #47285 — можешь в последний добавить свой комментарий по воспроизводимости, но есть сомнение, что кто-то будет чинить устаревшую версию (хотя ветка 5.2 упорно цепляется за жизнь ввиду множественных отличий от 5.3, но ее смерть неизбежна).

Если посмотреть на ChangeLog, то можно увидеть, что ошибки исправляются, вносятся новые — в общем идет развитие.

Как вариант, собрать на хостинге собственную сборку php и назначить ее в качестве обработчика.

Здравствуйте, Eugeny__, Вы писали:

E> Найди мне хоть один пруф. Допустить теоретически — может. Практически же прецедентов не было.

Отвечает Cyberax

Автор: Cyberax
Дата: 05.11.10

Здравствуйте, Anton Batenev, Вы писали:

AB>Как вариант, собрать на хостинге собственную сборку php и назначить ее в качестве обработчика.
Шела нет, system() запрещен. У клиента там большой проект, переезжать он не будет ни на другой хостинг, ни на другой php. Так что бага в моем случае перманентная, а судя по багтрекеру, совсем не новая.

P.S. Написал свой вариант "следующего воскресенья" и других подобных вызовов, скорость процессинга данных упала на 40%. Сабж.

P.P.S. В какой версии функция crc32() научится принимать значение от предыдущей итерации, чтобы можно было посчитать CRC чего-нибудь большего, чем фразы "Hello world" не используя своей php-реализации с потерей 95% производительности? Почему мне нужно реализовывать хитровывернутый (и, как следствие -- тормозной, ибо писать его приходится на том же php) алгоритм объединения двух независимых CRC в один?

Здравствуйте, quwy, Вы писали:

q> Шела нет, system() запрещен. У клиента там большой проект, переезжать он не будет ни на другой хостинг, ни на другой php. Так что бага в моем случае перманентная, а судя по багтрекеру, совсем не новая.

Сочувствую. Но там, где нет шелла и запрещен вызов system/popen/exec/etc разговор об альтернативных языках для веба типа питона/руби вообще лишен смысла. Так же у меня не вяжется словосочетание "большой проект" и "shared hosting" — выделенный сервер стоит всего 1500 рублей в месяц и большой проект наверняка его окупит с лихвой.

q> P.S. Написал свой вариант "следующего воскресенья" и других подобных вызовов, скорость процессинга данных упала на 40%. Сабж.

"Наивное" решение, которое не работает в первой неделе 1970 года и исходит из постулата, что в секунду координации значения UNIX time повторяются:

<?php

date_default_timezone_set("Europe/Moscow");

function nextSunday ($timestamp)
{
    $SECONDS_PER_DAY = 86400;

    $timestamp_midnight    = $timestamp - ($timestamp % $SECONDS_PER_DAY);
    $timestamp_day_of_week = ($timestamp_midnight / $SECONDS_PER_DAY - 3) % 7;
    $timestamp_day_shift   = $timestamp_day_of_week == 7 ? 7 : 7 - $timestamp_day_of_week;

    return $timestamp_midnight + $timestamp_day_shift * $SECONDS_PER_DAY;
}

echo date("c\n", nextSunday(mktime(23, 59, 59, 1, 1, 1970))); // error
echo date("c\n", nextSunday(mktime(23, 59, 59, 1, 2, 1970))); // error
echo date("c\n", nextSunday(mktime(23, 59, 59, 1, 3, 1970))); // error
echo date("c\n", nextSunday(mktime(23, 59, 59, 1, 4, 1970))); // error
echo date("c\n", nextSunday(mktime(23, 59, 59, 1, 5, 1970))); // ok
echo "\n";
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 25, 2010)));
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 26, 2010)));
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 27, 2010)));
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 28, 2010)));
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 29, 2010)));
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 30, 2010)));
echo date("c\n", nextSunday(mktime(23, 59, 59, 10, 31, 2010)));

?>

Тест с strtotime: 64.84 user 66.24 system 2:12.13 elapsed (~132s)
Тест с решением выше: 26.74 user 0.02 system 0:26.95 elapsed (~27s)

Т.е. типа ускорили в ~5 раз. Хотя я мог допустить грубую ошибку где-то, т.к. под утро голова не соображает.

q> P.P.S. В какой версии функция crc32() научится принимать значение от предыдущей итерации, чтобы можно было посчитать CRC чего-нибудь большего, чем фразы "Hello world" не используя своей php-реализации с потерей 95% производительности? Почему мне нужно реализовывать хитровывернутый (и, как следствие -- тормозной, ибо писать его приходится на том же php) алгоритм объединения двух независимых CRC в один?

hash_file?

Здравствуйте, quwy, Вы писали:

S>>и какая нужда заставила заняться гадостью?
Q>Деньги.
Вот потому и жив

Если бы люди не думали о деньгах, то есть о хлебе насущном, мноооого чего в мире было бы по другому.

S>>у C++ память течет
Q>Только по вине быдлокодера
Да-да, старая пестня — если бы программисты не были бы людьми, то ...

Только получается — быдлокодер получает деньги за php и жабу, а гений на С++ вынужден голодать.

Такая вот несправедливость мировая — за разную квалификацию — приблизительно одна и та же оплата

Здравствуйте, Abalak, Вы писали:

A>Здравствуйте, quwy, Вы писали:

S>>>и какая нужда заставила заняться гадостью?
Q>>Деньги.

A>За последние несколько недель встречаю второго человека, который взялся за пхп ради денег. Куда мир катится?

А за PHP и берутся ради денег...
Мне он деньги приносит, я доволен. Что еще нужно?

Здравствуйте, quwy, Вы писали:

Q>Почему это тормозное косорылое угробище не сгинуло во тьме веков?
Q>Причины? Зашкаливающее количество неграмотных школокодеров? И получается он будет жить всегда?

Написано очень много документации и не нужно ничего настраивать, чтоб работало с httpd хоть под виндой, хоть под линухой и т.д.

У меня сервер IPтелефонии работает на asterisk, админка на php, статистика в mysql. Знаю что будет работать и на Linux и на Wondows без особых затрат времени. Разница только в планировщике задач, в linux это crond