On Tue, Jun 13, 2006 at 07:51:55PM +0400, Dmitry V. Levin wrote:
> On Tue, Jun 13, 2006 at 07:47:25PM +0400, Alexey Tourbin wrote:
> > On Tue, Jun 13, 2006 at 07:25:28PM +0400, Dmitry V. Levin wrote:
> > > > В общем написать osec на шелле/перле и завернуть его в qa-robot
> > > А зачем?
> > 
> > Юниксвейнее.  Например, зачем использовать fts(3), если есть find(1)?
> fts быстрее.

Я профилировал.  Есть полтора соображения: 0) профилировать невозможно,
потому что буферный кеш вносит свою лепту: результаты последовательных
запусков могут отличаться в разы; 1) основное время уходит на чтение
файлов с диска, т.к. надо вычислять md5sum.  Т.е. bottleneck в данном
случае -- это как раз IO, и его никак оптимизировать нельзя.  Этот пайп,
который 'find /lib /usr/lib |perl ...' -- это всего два процесса на весь
psec.  Вот если предпринять попытку обойтись без перла, т.е. типа

find /lib /usr/lib |while read -r f; do md5sum=$(md5sum "$f")

тогда для обработки каждого файла потребуется ещё минимум один
fork+exec, что уже может заметно сказаться на скорости.

> > И зачем использовать cdb(3), если можно писать названия файлов и их
> > md5sum прямо в stdout?
> cdb быстрее.

Быстрее чего?  Писать в stdout всяко быстрее.  Потом sort(1) отсортирует
по первому полю, и join составит список старых/новых файлов.  Без
предварительной сортировки main.cc:check_changes() быстрее работать
не может, поскольку на каждый ключ нужен отдельный lookup (проход по
дереву?), а при слиянии lookup не нужен.  Т.е. osec вручную реализует
comm/join для двух cdb файлов.

> > А qa-robot сделает diff между двумя выводами.
> > С++ в таком раскладе совсем не нужен.
> Другими словами, долой оптимизацию! :)

Оптимизацию чего?  Если выяснится, что пайп 'find |perl' откусывает
заметное время (во что я не верю), то можно будет и на чистом перле
переписать.  Во всяком случае у меня сложилось такое представлениие, что

t(disk_IO) >> t(system_call) >> t(library_call)

где t -- время и ">>" означает "много большое" (минимум на порядок).