Во-первых, вы должны определить, что вы подразумеваете под «производительностью», и сколько вы готовы отказаться, чтобы получить это.
Большинство людей скажут вам, что это означает что-то вроде «завершает задачу быстрее всего». Это не очень интересно, хотя. Если вам нужно действительно быстрое решение, вы не должны использовать ни PHP, ни Perl. Вы хотите подойти как можно ближе к голому металлу. Языки более высокого уровня тратят много времени, потому что они являются инструментами общего назначения. Они должны быть готовы сделать что угодно, а не только то, что вы хотите сделать. Как таковые, они отказываются от некоторой скорости для гибкости.
О, но программирование на таком низком уровне занимает слишком много времени и не переносимо. Так что теперь вам нужно учитывать время разработки, необходимое для достижения того момента, когда вы программируете просто приемлемо быстро. Если он завершается в мгновение ока, нужно ли вам, чтобы он закончился за полминуты? Возможно, язык высокого уровня достаточно быстр.
Некоторые люди скажут вам, что Perl (или другой язык) действительно прост, и для опытного программиста. Это не поможет, если вы еще не знаете Perl. Язык на самом деле не имеет значения. Если вы знаете PHP, но не знаете Perl, возможно, сегодня вечером у вас будет PHP-решение Если вы прочитаете мою книгу Learning Perl , которую разумный человек может выполнить за 40 часов, если он выполнит все упражнения, возможно, у вас есть решение Perl через две недели. Наоборот, человек с разумными навыками Perl может сегодня вечером получить решение Perl, но через неделю - решение PHP. Это дополнительное время разработчика может не стоить этого.
Однако общая проблема, с которой я сталкиваюсь у любого программиста, является основной причиной неэффективности: они просто не знают, как программировать, и их это не волнует. Конечно, они могут создать синтаксически допустимую программу, и они могут связать воедино ряд операторов Rube Goldbergesque, которые в конечном итоге дают желаемый эффект, но они не знают, как проектировать, эффективно использовать ресурсы и так далее.
Однажды такой претендент, которого я должен был оценить, настоял, чтобы компания покупала больше оборудования, несмотря на то, что загрузка ЦП никогда не превышала 5%. Он сделал огромные хэши в памяти, чтобы все настроить, занимая 500 МБ на хэш и работая на 16 дочерних процессах apache. Его очень простая программа для загрузки файла и помещения его в базу данных была ограничена физическим объемом оперативной памяти в машине. Его выступление было очень низким, потому что он не знал, что делает. То, что он использовал Perl, не имело значения.
Действительно, теперь удаленный ответ на этом сайте использовал 16 ГБ, чтобы сгенерировал 100 случайных чисел . Если вы знаете, как разрабатывать программы, вы не собираетесь делать глупости на любом языке.
Некоторые люди любят указывать на тесты для игрушечных программ. Проблема в том, что вы никогда не интересуетесь написанием игрушечных программ, поэтому тесты не имеют значения. Тим Брэй участвовал в конкурсе Winde Finder , и, как ни старался, чтобы решение Ruby или Erlang победило, Perl взял приз. Не слишком волнуйтесь об этом, хотя. Обратите внимание, что лучшие 20 решений были получены только несколькими людьми, и что большинство языков также имели очень плохие решения. Некоторые из лучших решений были в Erlang, хотя сам Тим не был достаточно опытным в Erlang, чтобы получить такие результаты (и он не пренебрегает, заметьте). Он также отмечает, что решения Ruby работали быстрее на ноутбуке Mac, чем на Sun T5120. Мало того, но многие из лучших решений, независимо от языка, использовали одну и ту же технику: они отображали файл. Программы были в основном одинаковыми. Получение картины еще? Язык программирования даже близко не является важным решением.
Теперь, может быть, некоторые люди начинают видеть угол производительности: сколько я должен вкладывать в то, что получаю? Многие из моих коллег по Perl будут насмехаться над PHP, делать глупые замечания о его дизайне и т. Д., Но они полностью игнорируют тот факт, что для некоторых базовых вещей нужно приложить очень мало усилий, чтобы получить то, что вам нужно. Тем не менее, они, вероятно, правы, что вы жертвуете многим, привязывая себя к модели PHP. Может быть, PHP дает вам краткосрочный выигрыш, который полностью действителен, но ставка на ферму не может быть правильным долгосрочным решением, скажем, когда вы хотите перейти на веб-сервисы вместо веб-страниц (я смотрю на тебя, Sourceforge).
И это просто продолжается оттуда. Вы должны выяснить, что вы хотите для «производительности», выяснить, как все ваши решения влияют на это, а затем выбрать решение, которое подходит именно вам. Это долгий путь, чтобы сказать, что никто не может ответить на этот вопрос для вас, и что даже для вас ответ может измениться в зависимости от новых требований.