самый быстрый скриптовый язык программирования?

Если производительность важнее всего остального, не используйте язык сценариев. Тем более, что у вас есть полный контроль над стеком технологий. Скомпилированные языки будут работать лучше для операций с интенсивным использованием ЦП.

G-WAN — это аккуратный веб-сервер: он основан на концепции «скриптов C»:

Сценарий C — это просто исходный код C, который компилируется веб-сервером, а затем загружается в защищенную память. Он будет вызываться веб-сервером, когда будет сделан запрос к сервлету. Сервлет, скомпилированный компилятором C, "так же быстр", как и обычная компиляция программы C. Однако преимущество сценариев C перед, например, CGI или FastCGI заключается в том, что скомпилированная программа находится в том же пространстве памяти, что и веб-сервер. Это уменьшает накладные расходы на связь (либо путем создания процесса, в случае CGI, для каждого запроса, либо сокета для FastCGI).

Веб-сервер использует метод выбора/опроса: неблокирующий ввод-вывод. Тем не менее, есть опрятная вещь. Каждая программа может быть написана так, как если бы она использовала блокирующий ввод-вывод. Поскольку веб-сервер сам компилирует каждый сценарий C, он может преобразовать программу для использования неблокирующего ввода-вывода. Благодаря этому он может связываться со сторонними библиотеками (например, доступ к базе данных) и по-прежнему использовать неблокирующий характер ввода-вывода: без переключения контекста потока/процесса.

Инструменты, предоставляемые для программирования сценариев C, — это, например, кэширование и безопасные буферы. Следующая (еще не выпущенная на момент написания этого поста) версия также будет включать хранилище ключей и значений.

С точки зрения производительности: есть несколько доступных тестов, показывающих, что он превосходит любой другой веб-сервер, однако я им не доверяю. Попробуйте написать небольшую программу, интенсивно использующую процессор, на C и, например, на PHP. Пусть сценарий C работает в G-WAN, а сценарий PHP — в Apache, а сами выполните тест производительности.

Это еще не все, но это выходит за рамки этого вопроса.

Некоторыми недостатками G-WAN является то, что он разработан только одним человеком. Но есть форум, где можно задавать вопросы.

Простота использования ограничена вашими навыками в C. Однако предоставленный API прост. В нем все еще есть некоторые несоответствия и (на мой взгляд) некрасивые детали, но это не проблема. Более серьезная проблема заключается в том, что не гарантируется совместимость каждой версии с предыдущими версиями, и вам, возможно, придется переписать ее.

Если вы хотите быть в безопасности: используйте независимость C от платформы: разрешите компилировать ваш код в программы (Fast)CGI, а также использовать G-WAN. В случае сбоя G-WAN вы всегда можете вернуться к Apache (Fast)CGI (см. http://www.fastcgi.com/ для API).

Javascript постоянно изучается и оптимизируется для использования на мобильных устройствах, поэтому на реальных полноразмерных серверах он работает ОЧЕНЬ быстро. Ознакомьтесь с Node.JS, проектом реализации javascript на стороне сервера для обслуживания веб-страниц: http://nodejs.org/

Начните с определения того, действительно ли производительность вашего приложения зависит от языка или от какого-либо другого фактора (например, от запросов к базе данных). Возможность кэширования результатов также может быть очень важным фактором.

Что касается производительности, то используемый язык стоит далеко в списке важных моментов, которые необходимо проверить, и вариант использования также влияет на то, какой язык лучше. Например, если у вас есть много регулярных выражений для проверки, вы должны проверить поддержку регулярных выражений на языке-кандидате и т. д.

Для обработки изображений наиболее важным моментом, вероятно, будет используемая вами базовая библиотека изображений, обычно написанная на C. Я имею в виду случай ImageMagick, потому что в настоящее время я использую его. Он доступен в качестве библиотеки для большинства языков, а уровень языка сценариев необходим только для вызова функций библиотеки, и используемый язык на этом уровне не сильно изменится (но кэширование предварительно вычисленных изображений результатов может значительно изменить производительность). Этот вариант использования, вероятно, будет аналогичен вызову криптографической библиотеки.

Если производительность действительно является такой проблемой, для обработки изображений вы также можете рассмотреть возможность использования библиотеки, которая работает с картами ускорителей GPU (библиотеки с поддержкой cuda или openGPU).

Что ж, если вы используете базу данных с большим объемом данных, вы потратите на это больше времени, чем на запуск скрипта php, asp или (вставьте здесь другие разновидности) скрипта
Если вы можете, вам следует создать макет вашего приложения (или в по крайней мере, сегмент более ресурсоемких частей базы данных или процессора) и попробуйте сравнить их

LuaJit (Lua) — самый быстрый язык сценариев с технологией JIT.

если вам нужно самое быстрое веб-приложение на стороне сервера (которое не всегда скриптует), это будет g-wan.. вы можете использовать c, c++, java..

ASP.NET также достаточно быстр практически для всего, но довольно дорогой.

php с хип-хопом было бы проще всего выучить, а также достаточно быстро.

это зависит от того, сколько запросов вам нужно.. и как быстро вы изучаете язык ^^ не забывайте кэшировать статические данные (используя memcache или nosql)

Обновление: кажется, что Java 7 с использованием NIO.2 удалось превзойти Gwan с использованием C, но почти в 2 раза по времени, это невероятно, но вы можете провести несколько простых тестов.

Единственным недостатком Java является то, что он не может интегрировать разделяемые библиотеки, построенные на C. Я готов бросить вызов кому-то, кто докажет, что я не прав, что Java NIO.2 медленнее, чем C.

Я рекомендую язык программирования Java; это не язык сценариев, но, вероятно, это самый быстрый язык программирования, который можно использовать для программирования веб-приложений. Я также рекомендую использовать фреймворк, такой как Spring, для лучшего опыта программирования (по сравнению с «сырым» программированием сервлетов Java).

Быстрый язык сценариев — это ASP, за которым следует PHP, но если вы хотите, чтобы приложения масштабировались до неограниченной скорости, используйте C++ или Java. Google Search использует C++ Gmail использует Java YouTube = Python Twiiter раньше использовал Ruby, теперь они перешли на Java Facebook = PHP на интерфейсе и немного Java на сервере

Но я рекомендую PHP во внешнем интерфейсе и C++ во внутреннем.