[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Функционал и интерфейс



В Вто, 17/03/2009 в 00:05 +0300, Alexey Pechnikov пишет:
> Hello!
> 
> On Monday 16 March 2009 20:48:44 Покотиленко Костик wrote:
> > > Про потребляемую память забываем.
> >
> > И яркий пример тому тот же spamassassin. Он одновременно может только 5
> > потоков обрабатывать, как написано в документации, "unless you know what
> > you're doing".
> 
> А что, все программы на С умеют работать с тысячами потоков? Интереснее работа 
> с событиями в тикле, к примеру, когда не требуется плодить тучу потоков, чтоб 
> одновременно снимать данные, скажем, с десятка цисок.

Это вопрос больше алгоритмов, и меньше языков. На языках более высокого
уровня такое тяжело сделать компактно.

> > Вы правы, когда говорите, что
> > - нет смысла экономить килобайты и мегабайты памяти, когда речь идёт о
> > ПО работающем с единственном экземпляре, т.к. память дешёвая;
> > - нет смысла оптимизировать тысячи и сотни тысяч MIPS'ов в процедуре,
> > которая выполняется раз в относительно большой период времени, т.к. Вы
> > сэкономите не больше секунды.
> 
> И в чем заключается "экономия"? 
> 
> Например, работа со строками на С без использования специальных библиотек 
> значительно менее эффективна, чем в скриптовых языках. Попробуйте написать 
> программу на С, которая по обработке регекспов обгонит перловый скрипт. 
> 
> Ну, возьмем другой пример - сжатие/распаковка данных. Лично я предпочитаю 
> делать расширения к SQLite, чтобы можно было пользоваться как из тикля, так и 
> из шелла, в данном случае используем системную zlib, в итоге получаем:
> $ cat compress.c |wc -l
> 120
> И это с комментариями и инструкциями по сборке! И в моем полном распоряжении 
> эффективный инструмент, доступный как из программы, так и в консоли. Плюс 
> SQLiteMan, написанный С++, и некоторые другие проекты пользуются этим и 
> другими модулями, при том, что я при написании кода могу совершенно не 
> беспокоиться, на чем будет сделано клиентское приложение. Вот это и есть 
> эффективность (оптимизируем именно то, что нуждается в оптимизации) плюс 
> повторное использование кода. Ваши же десятки и сотни килобайт кода, который 
> годится только для одного вашего проекта, никто и читать не станет, проще 
> заново написать.

Хорошее решение то, что работает.

-- 
Покотиленко Костик <casper@meteor.dp.ua>


Reply to: