5000 глобально видимых функций - это уж кто как пишет. Насколько я понимаю, на php вполне можно строить архитектуру кода в соответствие с ООП - методы классов же не глобальны. Или я ошибаюсь?
В нескольких местах Вы упоминаете о скорости парсинга кода. Если такой вопрос вообще встает (т.е. сайт становится посещаемым), то первое, что надо сделать - это отказаться от парсинга на каждый запрос. Файл скрипта должен парситься один раз при старте сервера, и дальше лежать в памяти в виде исполняемого байт-кода (для этого есть всякие код-кэши и оптимайзеры). И тогда между, например, 'foo' и "foo" не будет ровно никакой разницы.
В распространенных ОС (freebsd, linux) блокировки файлов лишь рекомендательные - то есть наспех дописанный скрипт, в котором забыли проверить блокировку, сможет параллельно писать в этот файл.
Поэтому лучше сначала писать во временный файл со случайным именем (разумеется, открывать его надо с флагом O_EXCL) - а затем переименовывать в нужное имя. Переименование атомарно на подавляющем большинстве систем.
Ты весьма категоричен :) В вебе все-таки есть места, где Си не только уместен, но и практически незаменим. Например - поисковики. Тот же Яндекс бы просто не выжил, если бы его индексаторы и особенно поисковые демоны были бы написаны на perl. Другой пример - рекламные сети. У всех (ну, всех не знаю, но за несколько ручаюсь) крупных баннерных сетей ядро написано на C/C++ (хотя все интерфейсы и прочие сервисные скрипты - конечно пишут на скриптовых языках).
Ну, мое развитие как программиста идет по спирали (как и все в этом мире). На С я уже писал (обработка графики и аудио), со стремлением к оптимизации, анализом сгенеренного компилятором кода и кусками на ассемблере. Затем сдвинулся в сторону web и беззаботно пересел на perl. Теперь вот снова столкнулся с высоконагруженными приложениями, уже в этой области :)
Ага, видимо пора и тут написать disclaimer: я намеренно воздержался от комментариев касательно простоты, красоты и читабельности кода: perl слишком широк, чтобы ставить тут какие-то рамки. Пусть эти вопросы каждый решает для себя - я же лишь привожу факты ;)
На самом деле - конечно в данном случае map некрасиво, а for соответствует стилю. И конечно я в 99.99% случаев напишу for. Но ведь это не мешает включить в benchmark оба варианта, верно? ;)
А способы типа @$list = ( 456, ... ) и @list = ( 456, ... ) не подходят, так как теряют значения остальных элементов массива. Как я сказал, я в данном тесте исходил из того, что элементы массива - соответствуют полям объекта, и некоторые из них мы обновляем.
Точно, забыл этот способ включить! Спасибо большое, обновил текст. Он, конечно, не самый быстрый (как и в случае хэша, прямое присваивание работает в 2.5 раза быстрее) - но его тут явно не хватало для полноты картины.
Очень сомнительная экономия - для сайтов типа google пользователь обычно делает много загрузок страниц сайта, а однажды запрошенный css файл надолго кэшируется в браузере. На самом деле, стили прописывают в странице не для экономии трафика, а для визуального ускорения загрузки страницы - Яндекс, например, тоже частично выносит стили в код главной страницы, чтобы основной элемент - форма поиска - появилась сразу и в правильном оформлении.
После, пока он еще учился в школе, Джонатан Гей бросил заниматься профессиональным программированием.
В английском слово break означает не только перерыв, но и прорыв, первое появление. Поэтому фразу:
Jonathan Gay got his break in professional programming while still in high school.
следует переводить как "Джонатан Гей начал заниматься профессиональным программированием еще в школе" - что, согласитесь, меняет ее смысл на противоположный ;)
Макс, а почему не список?! Я был уверен, что гуру тут напишет ul. По крайней мере, pepelsbey бы точно ul написал :) А вариант с dl мне совсем не нравится: не логично это, заголовок комментария никак не является пояснением, расшифровкой к имени юзера.
По моему, начать тут надо с "выравнивания", т.е. компенсации волнообразного искажения. Алгоритм искажения довольно простой, а зацепиться можно за то, что почти в каждой captcha-фразе есть буквы с прямыми (и даже вертикальными) линиями - d, b, h и т.п. То есть можно итеративно пробовать "обратные" преобразования, пока не найдем максимум прямых вертикальных линий - а дальше стандартно, разделяем и распознаем.
Непосредственно распознавать звуковые капчи я не пробовал, но много работал со звуком, поэтому могу сказать - звуковые капчи по идее тоже просто распознаются. По крайней мере "посчитайте низкие звуки" - это вообще элементарно. Чуть сложнее - произнесенные голосом слова (цифры например) - но тут тоже все сводится к тому, что звук будет формироваться из заранее записанных кусков, а значит его можно обратно на эти куски разобрать.
В любом случае, проблема всех captcha в том, что они синтезируются машиной - а значит могут быть машиной разобраны.
В крупных европейских городах общественный транспорт совсем не такой, как у нас. Там на каждой остановке в центре табло: "до прихода автобуса - 2 минуты". А внутри самого автобуса - табло с временем прибытия на каждую остановку. И в метро то же самое.
В нескольких местах Вы упоминаете о скорости парсинга кода. Если такой вопрос вообще встает (т.е. сайт становится посещаемым), то первое, что надо сделать - это отказаться от парсинга на каждый запрос. Файл скрипта должен парситься один раз при старте сервера, и дальше лежать в памяти в виде исполняемого байт-кода (для этого есть всякие код-кэши и оптимайзеры). И тогда между, например, 'foo' и "foo" не будет ровно никакой разницы.
Поэтому лучше сначала писать во временный файл со случайным именем (разумеется, открывать его надо с флагом O_EXCL) - а затем переименовывать в нужное имя. Переименование атомарно на подавляющем большинстве систем.
На самом деле - конечно в данном случае map некрасиво, а for соответствует стилю. И конечно я в 99.99% случаев напишу for. Но ведь это не мешает включить в benchmark оба варианта, верно? ;)
В любом случае, проблема всех captcha в том, что они синтезируются машиной - а значит могут быть машиной разобраны.