LINUX.ORG.RU

Зависит от программы. Попробуй найти узкое место. После этого можно начать нормальное обсуждение.

ugoday ★★★★★
()

сперва надо профилировать.
многие вещи можно сильно ускорить на уровне самого питона,
если понимать механизмы работы интерпретатора,
либо используя специальные пакеты -- numeric python, итп.
также очень рекомендую попробовать psyco, обычно он ускоряет в несколько раз

anonymous
()
Ответ на: комментарий от anonymous

>если понимать механизмы работы интерпретатора,

PHP, Python не для тех, кто понимает механизм работы интерпретатора, когды же это поймут все. Это простые в освоении, легкие языки, на которых пишут первоклассники в программировании. Программист, понимающий механизмы работы интерпретатора, выберет уже компилируемый язык себе для проекта, типа Ruby, Pascal

anonymous
()
Ответ на: комментарий от Valeriy_Onuchin

Если большая часть ресурсов затрачивается во внешней либе (которую дёргает программа) или процесс упирается в базу данных, или в сеть, то производительность питона и асма одинакова.

Смерть пионерам!

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

Умри несчастный! Делфи съел 1.5 года моей жизни.

ugoday ★★★★★
()

задача - парсинг своебразных "логов", ни к сети, ни к чему-либо еще обращения нет. используется только жесткий диск и процесорное время. размеры файлов довольно большие - 200-500 мегов. поэтому и время значительное тратиться.

anonymous
()
Ответ на: комментарий от anonymous

>задача - парсинг своебразных "логов", ни к сети, ни к чему-либо еще обращения нет. используется только жесткий диск и процесорное время. размеры файлов довольно большие - 200-500 мегов. поэтому и время значительное тратиться.

С++ тут не спасет. Тогда лучше пользоваться чистым С.

По хорошему, надо профилировать сначала. Какая конкретно функция берет все время. В питоне много взаимозаменяемых модулей.

atoku ★★★
()
Ответ на: комментарий от Valeriy_Onuchin

>вопрос равнозначен - "на сколько питон медленее ассемблер"

c++ это совсем не ассемблер

>Смерть пионерам!

вот тут ты прав

anonymous
()
Ответ на: комментарий от atoku

>С++ тут не спасет. Тогда лучше пользоваться чистым С.

тут ты не прав, современные оптимизируешее компиляторы дадут на коде
использушем stl и iostream и чистый C разницу в 2-3 процента,
когда разница в объеме кода будет процентов 70.

С стоит использовать только если очень нужна быстрота или нет компилятора C++
для данной архитектуры (например в ядре ОС).

anonymous
()
Ответ на: комментарий от anonymous

Порядков ты не получишь. Разы максимум. Афаик, regexp engine сейчас научились делать достаточно хорошо. Можешь реализовать парсинг в виде цэшной функции и слинковать со своей программой. Результат запость сюда. Будет инетересно посмотреть.

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

>С стоит использовать только если очень нужна быстрота или нет компилятора C++ >для данной архитектуры (например в ядре ОС). Вы прямо так говорите, как будто С и С++ - 2 компилятора одного и того же языка. Если в моей программе не нужны классы, STL, наследование, исключения и пр. мне тоже надо неприменно использовать С++?

anonymous
()
Ответ на: комментарий от anonymous

>С стоит использовать только если очень нужна быстрота или нет компилятора C++ >для данной архитектуры (например в ядре ОС).
Вы прямо так говорите, как будто С и С++ - 2 компилятора одного и того же языка. Если в моей программе не нужны классы, STL, наследование, исключения и пр. мне тоже надо неприменно использовать С++?

anonymous
()
Ответ на: комментарий от Valeriy_Onuchin

Eсли отвечачать конкретно на вопрос, то ... как ты знаешь, такие мудозвоны, как я используют C/C++ в качестве интерпретатора http://root.cern.ch, http://carrot.cern.ch

Всегда есть возможность сравнить "на сколько C/C++ interpretator медленее compiled C/C++".

Ответ - более, чем в 3-10 раз. Думаю, что с питоном, PHP etc., та же история (умножай на пи, не ошибешься).

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

> Вы прямо так говорите, как будто С и С++ - 2 компилятора одного и того же языка

Это есть истина.

Valeriy_Onuchin ★★
()

ИМХО, для парсинга логов есть perl

theserg ★★★
()
Ответ на: комментарий от anonymous

>PHP, Python не для тех, кто понимает механизм работы интерпретатора

вызывающе ламерское мнение, почитай эссе Гвиды на python.org, питон двуликий язык, с кучей незаметных ламерскому глазу приблуд

ninja
()
Ответ на: комментарий от Valeriy_Onuchin

С === это нишевый ЯП. Ниша его --- системное программирование. Там он хорош, но применять его вне этой ниши самое настоящее пионерство и есть.

ugoday ★★★★★
()
Ответ на: комментарий от ninja

прочитал.
нет ,я не против революции в software.
C/C++ - плохой язык.
Мое понимание, что то , куда надо двигаться -
это COM, Reflection, buitin-interpretor, builtin-debugger etc.,
но никак не Pyton, PHP, LISP.
Жалко, у пчелки, что такие ентузазисты,
как Витаталик пропадают на Х...

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

>Мое понимание, что то , куда надо двигаться - это COM, Reflection, buitin-interpretor, builtin-debugger etc., но никак не Pyton, PHP, LISP.

хм, интересный у тебя компас, мне конечно инетерсно откуда такие заморочки, но по моему это баянная тема, к примеру КОМ это ну да хрень, которой можно попользоваться, подзаработать немного денег, но уж точно это не место куда надо двигаться, ща погоди билии уйдет, микрософт зачахнет, и скорчится

ninja
()
Ответ на: комментарий от Valeriy_Onuchin

Молодой человек, вы не могли бы выразить свою мысль другими словами? Непонятно-с.

ugoday ★★★★★
()
Ответ на: комментарий от ninja

вероятность невелика, но попытаться стоит.

anonymous
()
Ответ на: комментарий от ugoday

>Если большая часть ресурсов затрачивается во внешней либе (которую >дёргает программа) или процесс упирается в базу данных, или в сеть, то >производительность питона и асма одинакова.
Вот только как вы будете этот питон профилировать в отличие от C ???

anonymous
()
Ответ на: комментарий от anonymous

известно как:

import profile; profile.run("test()")

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.