Re: Анонс: легковесна я система полнотексто вого поиска

2010-02-06 Пенетрантность Yuriy Kaminskiy
On 06.02.2010 13:06, Alexey Pechnikov wrote:
> преимущества не просто сомнительны, а вовсе неуловимы, т.к. у пользователя 
> подобных файлов не бывает - их нельзя скачать из интернет
%0A
> или создать офисными программами.
Ctrl-Shift-ua
впрочем, я в своих скриптах на существование таких файлов тоже забиваю ;-)
[но одно дело мои скрипты для локального использования, другое - программа для
пользования другими в непредсказуемом окружении; как минимум, непонимание таких
имён файлов должно быть документированно БОЛЬШИМИ БУКВАМИ]


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Анонс: легковесна я система полнотексто вого поиска

2010-02-05 Пенетрантность Maxim Nikulin

Alexey Pechnikov wrote:

On Friday 05 February 2010 18:25:46 Victor Wagner wrote:


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


Стоит решать названную задачу совсем другим методом. А именно - команда find
с нужными параметрами выбирает файлы, к примеру, изменившиеся за последние
24 часа и скармливает их список индексатору.


На всякий случай: и тех файлов, которые принесли за это время, хоть и 
менялись они год назад.


--
Максим Никулин



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Анонс: легковесна я система полнотексто вого поиска

2010-02-04 Пенетрантность Yuriy Kaminskiy
On 04.02.2010 22:25, Alexander Galanin wrote:
> On Thu, 4 Feb 2010 22:17:31 +0300
> Alexey Pechnikov  wrote:
> 
>> Итого с exec почти вдвое медленнее.
>>
>> cpu cores: 2
> ^^^ --- наверно, тут собака зарыта
> 
> Потому как я на однопроцессорных машинах проверял и exec закономерно
> выигрывал.
Нет, на двухядерной машине у меня результаты точно такие же, как у тебя:
[etch, кустарное 2.6.27, bash 3.1.17, amd x2 4850e]
$ /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-fork"
0.72user 1.03system 0:01.85elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+579973minor)pagefaults 0swaps
$ /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-exec"
0.72user 0.85system 0:01.60elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+492973minor)pagefaults 0swaps
$ cat /proc/cpuinfo|grep processor
processor   : 0
processor   : 1
user time тут, ясен пень, ничего значащего не показывает, смотреть надо на
system, elapsed и pagefaults. Как и ожидалось, в варианте с exec они заметно
меньше (хотя и не в разы) [btw, а вот в недопозиксе, типа цигвина, они могут
быть не то что в разы, а и вовсе в порядки].

Подозреваю, что тут скорее другое играет роль:
AP> model name  : Intel(R) Core(TM)2 Duo CPU T5470  @ 1.60GHz
AP> cpu MHz : 800.000
что-то мне говорит, что cpufreq тут включён, и частота плавает.
И вот это:
AP> 0.76user 1.93system 0:02.70elapsed 99%CPU [...]

AP> 0.34user 1.18system 0:01.68elapsed 91%CPU [...]

... прекрасно под это объяснение попадает: user time что с exec, что без него
должен быть примерно одинаковый (накладные расходы от лишнего fork уходят в
system time и всякие задержки->elapsed).
Перед такими тестами не помешает cpufreq-set -g performance (или, наоборот,
powersave). В противном случае есть шансы посравнивать тёплое с мягким.
Вообще в этом тесте многопроцессорность в лучшем случае играть никак не должна,
в худшем - мешать.
Эмулируем однопроцессорность:
$ taskset 01 /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-fork /dev/null"
0.72user 1.09system 0:01.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+579973minor)pagefaults 0swaps
$ taskset 01 /usr/bin/time sh -c "seq 1000 | xargs -n 1 ./x-exec /dev/null"
0.73user 0.84system 0:01.57elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+492973minor)pagefaults 0swaps
Как видим, результаты не отличаются (в пределах погрешности) от предыдущего
варианта.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org