Скорость выполнения python and c

#python #c #cpp

Всем привет!
Есть два кода один на С:
#include 
#include 

main()
  {
   FILE *fp;
   char *line = NULL;
   size_t len = 0;
   ssize_t read;

   fp = fopen("vlan112.txt", "r");

   while ((read = getline(&line, &len, fp)) != -1) {
       printf("%s", line);
   }

}

Время выполнения:
real    0m0.003s
user    0m0.000s
sys     0m0.004s
На python:
#!/usr/bin/env  python
# -*- coding: utf-8 -*-

for k in open("vlan112.txt"):
   print k.rstrip()

real    0m0.054s
user    0m0.044s
sys     0m0.012s
Текст в файле:
 10.1.12.64      00:25:22:2b:fa:98       vlan112 rjabchevskii

Почему такая большая разница в скорости? В текстовом файле 72 строки всего.    

Ответы

Ответ 1

Почти все время выполнения данной программы на Питоне занимает загрузка интерпретатора.


Ответ 2

На таких коротких примерах измерять скорость работы программ вообще нельзя.
Дело в том, что реально система подсчитывает количество прерываний исполняющегося
 процесса при возникновении аппаратного прерывания от системного таймера (а это обычно
в Linux 100, а в Windows (если не путаю) 1000 раз в секунду) отдельно для режима ядра
и режима пользователя.
И вообще, все время в системе (как для статистики, так и для планирования) меряется
именно в тиках таймера (сейчас 0.01 сек в Linux). 
При окончании процесса, если эти счетчики в нуле, идут не совсем честные рассчеты
(для чего, если често, не знаю), результаты возвращаются в struct rusage в wait3()/wait4(),
откуда их и берет команда time.
Если Вы запустите свои примеры десяток раз, то скорее всего увидите, что разброс
времени работы довольно большой.
И даже если мерять время не командой time, а вызывая, например gettimeofday() (возвращает
секунды и микросекунды) или clock_gettime() (секунды и наносекунды) в начале и конце
участка кода, то IMHO верить измерениям, короче 1 миллисекунды нельзя.
Желающие могут поэкспериментировать с повторяемостью замеров сами.


Ответ 3

Так вообще нельзя мерять. 
В реальном приложении запуск интерпретатора происходит 1 раз, если это не регулярно
запускаемый скрипт. Поэтому временем запуска интерпретатора можно пренебречь. Что там
эти пять секунд, если программа работает хотя бы полчаса.
Чтобы получить более реальные цифры, а не мифические 0.000 сек необходимо завернуть
код программы в большой цикл (например, 1000 раз).
Но при этом следует подумать - какое влияние на замеры окажет особенность работы
операционной системы (открытие файла довольно значительно по времени как правило) и
кэширования диска.
В данном конкретном случае нельзя говорить об плохой работе интерпретируемого языка
программирования. Так как тут большая часть времени (если исключить запуск интерпретатора)
- это ввод-вывод. Который от конкретного языка мало зависит.
И еще - в данном конкретном примере налицо зависимость от кэша диска. А погрешности,
вносимые диском, столь велики, что делать "гениальные" выводы про производительность
просто глупо.
Интерпретируемые языки и должны быть медленнее компилируемых, но на реальных задачах
разница не обязательно столь велика, как в данном случае. Например, на типичной задаче
- при выполнении запросов к базе данных - у компилируемого не будет преимущества.
Именно поэтому, что в реальности скорость работы программы не всегда зависит от языка,
интерпретируемые языки - широко используются в том числе и на нагруженных проектах
(например, сервисы Гугля в значительной степени реализованы на Python)
Правильным сравнением будет сравнение БЕЗ использования ВВОДА-ВЫВОДА. Тогда мы исключаем
факторы, не зависящие от языка программирования. То есть - реализуйте алгоритм, крутящийся
внутри, без чтения файлов и рисования графиков. Например, решето Эратосфена.
http://habrahabr.ru/post/133037/
http://easy-coding.blogspot.ru/2010/03/go-c-c.html