SarinА я недавно думал явой занятся...
У нее есть свои сильные стороны - но никак не в области создания интерфейсов (хотя... если есть желание построить интерфейс на окнах, повернутых на 52 градуса к горизонтали, java - идеальный выбор :)). Впрочем, отсутствие множественного наследования вкупе с желанием выделить максимально мелкие, специализированные классы, в любом случае приводит к тяжелому коду использования такой библиотеки, к куче противных технических деталей.

LelikkНе, ну о чем вы?
По омтимальности кода, Делфи сильно отстает, как ни крути.
Лично мерял?

http://rsdn.ru/article/devtools/perftest.xml

Чтобы не читать длинную статью - сразу выводы:

Резюме

Итак, практически все языки/компиляторы показали неплохую производительность. Назвать абсолютного лидера тяжело. В абсолютном зачете победу, скорее всего, одержал Intel C++, так как он почти всегда был около лидера, а в тесте «Float Test» ушел в такой отрыв, что получил гигантскую фору. Так же прекрасно выглядели VC 6, Delphi 6 и C#. VC был первым по количеству тестов, в котором он оказался первым (извините за каламбур). Но только при компиляции с включенной опцией inline-подстановки функций по выбору компилятора.

А что же наши неофиты? Да, в общем-то, неплохо. Java показала себя не самым быстрым средством, но на двух тестах (расчете p и «String Test») она была на йоту от лидерства.

C# стал победителем в тесте работы со строками и (если сравнивать результаты без inline-подстановок) в тестах «Доступ к членам» и «Доступ к методам». Почти во всех остальных тестах он был в числе призеров или показывал небольшое отставание от них. Единственный тест, где C# проиграл (и по крупному) – это «Tree Sort», где он занял последнее место. Как уже говорилось ранее, положение вещей может измениться к выходу финальной версии C# и VC.Net. Надеемся что эти изменения не только будут, но и будут в хорошую сторону.

SarinПротив ООП ничего не имею. Но объектно ориентированный код не может быть быстрее процедурного.
Как, впрочем, и медленнее.

Вещь, которую часто не замечают - ООП не вносит ничего принципиального нового в реализацию программы. Несложно написать программу, глядя в дизассемблированный листинг которой, нельзя будет сказать - она ООПшная или процедурная. Единственно, имея тормозную программу, можно сказать, что ее тормоза характерны для ООП - в первую очередь, неумеренное использование виртуальных функций.

SarinА виртуальных методов в VCL до жопы
На порядок-другой меньше, чем в яве

Торможение кнопки при клике на 0,0001 секунды, если честно, меня не сильно раздражает. Безусловно, есть вещи, которые на дельфе нормально реализуются только разработкой собственных, "быстрых" классов.

Я бы сказал, с точки зрения производительности у дельфы есть один глобальный недостаток - неумение делать inline. Самое интересное, что Turbo Pascal обладал такой возможностью, но при переходе на дельфу она исчезла. В результате в дельфе острее проявляется конфликт между "быстрым" и "хорошим" кодом. Второй, относительно редко проявляющийся - отсутствие шаблонов и/или макропроцессора.

Как пример второго - мой класс RecordList, на сайте. Сразу предупреждаю, что я не стремился сделать его "быстрым". Допустим, я хотел бы добавить туда поддержку многопоточности - но если я просто сделаю пару пустых виртуальных методов, Lock/Unlock, и буду вызывать их из основных подпрограмм - это весьма существенно затормозит в однопоточном режиме (проверял). Поэтому если добавлять - надо будет заводить еще флаг и писать что-нибудь идиотское типа if UseLocks then Lock. А если обжимать по скорости - так и вообще, хитрить с {$I} и {$IFDEF}, чтобы по одному исходнику получить два похожих класса.