Парадигмы программирования.
Когда-то давно (где-то в классе 11, то есть лет 12 назад)), я купил книжку по C++ (а может по Turbo Pascal). Где встретил очень интересное слово парадигма. Я тогда не понимал смысла этого слова, но из контекста употребления, можно было догадаться, что оно означает. Вообщем, тогда меня это слово зацепило.
И вот недавно размышляя очередной раз о производительности программного продукта моей горячо любимой компании - работодателя, я пришел к выводу, что проблемы производительности заложены в парадигме программирования. Да безусловно, это можно назвать проблемы проектирования системы или ещё чего. Но в данном случае я бы назвал это парадигмой. А именно парадигма группового и парадигма одиночного программирования.
Итак если ближе к сути вопроса.
Предположим у нас возникает задача передать письмо (можно даже предмет, чтобы не опиратся на наличие письменности. В историческом плане письменность появилась позже, чем человек сделал переход из одной парадигмы к другой) от человека А человеку Б. Для простоты пусть они живут в одном городе. В начале человек брал это письмо и нес его самостоятельно другому человеку. В дальнейшем для этой работы появились посыльные.
Тут остановимся, и отметим следущие характеристики процесса доставки писем. Время доставки определялось скоростью гонца, количество писем определялось фактически количеством гонцов (так как почтальонов ещё нет, и поэтому гонец нес фактически одно письмо только от А только к Б).
С увеличением потока писем, увеличивалась потребность в гонцах, однако так как поселение могло быть достаточно большим (территориально), а количество гонцов ограниченным, то очевидно возникнет проблема с гонцами. Так как гонцы занимаются тем, что все время находятся в пути, при этом у них одно письмо. Естественным решением было группировать письма, т.е. отдать все письма из одного района в другой район одному гонцу.
Здесь мы наблюдаем переход от одиночной парадигмы к групповой. В целях повышения обработки больших потоков писем, эффективнее их сгруппировать вместе (собрать в сумку гонца), потом перевезти (послать гонца), а потом разгруппировать (заставить гонца пройти по домам получателей писем в другом районе). При этом мы чуть чуть теряем на времени доставки (у нас появляются периоды, когда наше письмо ждет другие письма), но выигрываем на оплате труда гонца :-).
Вообщем, если эту идею развивать дальше, то становится понятно откуда появились почтамты, почтальоны и всё такое. Во всей этой истории (в данном контексте) важен переход к группированию однотипных действий.
Что мы имеем в программировании.
Пусть у нас есть некоторая процедура, которая по идентификатору объекта, достает этот объект из базы данных. Заметим, что процедура вытаскивания из базы данных, состоит из достаточно большого кол-ва операций (создать соединение, запустить транзакцию, выполнить запрос, прочитать данные, создать объект, сложить данные в объект, закрыть транзакцию, закрыть соединение).
Имея такую функцию (а это классическая функция для многих систем функция) удобно писать процедуры типа дай объект.. сделай что нить с этим объектом. И большинство программистов так и пишет код, не сильно задумываясь о последствиях (более того объектно ориентированный стиль программирования и современное увлечение трехзвенкой ведет именно к такому программированию).
Однако предположим, что объектов в таком цикле становится ... несколько тысяч. Что получается, что для обработки этого скопища объектов, мы тысячу раз создадим транзакцию, соединение, запрос. Это всё в данном случае будут накладными расходами.
Для простой борьбы с данными эффектами, реализованы пулы соединений, пулы запросов, реализованы кеши объектов. НО! Причина остается. Находясь в терминах парадигмы одиночного программирования невозможно существенно оптимизировать этот процесс. К сожалению, в программных комплексах, переход к групповой парадигме требует значительного усложнения программного кода, а также (что ещё хуже) отход от привычных алгоритмов по обработке данных (т.е. фактически к переобучению программистов).
И вот недавно размышляя очередной раз о производительности программного продукта моей горячо любимой компании - работодателя, я пришел к выводу, что проблемы производительности заложены в парадигме программирования. Да безусловно, это можно назвать проблемы проектирования системы или ещё чего. Но в данном случае я бы назвал это парадигмой. А именно парадигма группового и парадигма одиночного программирования.
Итак если ближе к сути вопроса.
Предположим у нас возникает задача передать письмо (можно даже предмет, чтобы не опиратся на наличие письменности. В историческом плане письменность появилась позже, чем человек сделал переход из одной парадигмы к другой) от человека А человеку Б. Для простоты пусть они живут в одном городе. В начале человек брал это письмо и нес его самостоятельно другому человеку. В дальнейшем для этой работы появились посыльные.
Тут остановимся, и отметим следущие характеристики процесса доставки писем. Время доставки определялось скоростью гонца, количество писем определялось фактически количеством гонцов (так как почтальонов ещё нет, и поэтому гонец нес фактически одно письмо только от А только к Б).
С увеличением потока писем, увеличивалась потребность в гонцах, однако так как поселение могло быть достаточно большим (территориально), а количество гонцов ограниченным, то очевидно возникнет проблема с гонцами. Так как гонцы занимаются тем, что все время находятся в пути, при этом у них одно письмо. Естественным решением было группировать письма, т.е. отдать все письма из одного района в другой район одному гонцу.
Здесь мы наблюдаем переход от одиночной парадигмы к групповой. В целях повышения обработки больших потоков писем, эффективнее их сгруппировать вместе (собрать в сумку гонца), потом перевезти (послать гонца), а потом разгруппировать (заставить гонца пройти по домам получателей писем в другом районе). При этом мы чуть чуть теряем на времени доставки (у нас появляются периоды, когда наше письмо ждет другие письма), но выигрываем на оплате труда гонца :-).
Вообщем, если эту идею развивать дальше, то становится понятно откуда появились почтамты, почтальоны и всё такое. Во всей этой истории (в данном контексте) важен переход к группированию однотипных действий.
Что мы имеем в программировании.
Пусть у нас есть некоторая процедура, которая по идентификатору объекта, достает этот объект из базы данных. Заметим, что процедура вытаскивания из базы данных, состоит из достаточно большого кол-ва операций (создать соединение, запустить транзакцию, выполнить запрос, прочитать данные, создать объект, сложить данные в объект, закрыть транзакцию, закрыть соединение).
Имея такую функцию (а это классическая функция для многих систем функция) удобно писать процедуры типа дай объект.. сделай что нить с этим объектом. И большинство программистов так и пишет код, не сильно задумываясь о последствиях (более того объектно ориентированный стиль программирования и современное увлечение трехзвенкой ведет именно к такому программированию).
Однако предположим, что объектов в таком цикле становится ... несколько тысяч. Что получается, что для обработки этого скопища объектов, мы тысячу раз создадим транзакцию, соединение, запрос. Это всё в данном случае будут накладными расходами.
Для простой борьбы с данными эффектами, реализованы пулы соединений, пулы запросов, реализованы кеши объектов. НО! Причина остается. Находясь в терминах парадигмы одиночного программирования невозможно существенно оптимизировать этот процесс. К сожалению, в программных комплексах, переход к групповой парадигме требует значительного усложнения программного кода, а также (что ещё хуже) отход от привычных алгоритмов по обработке данных (т.е. фактически к переобучению программистов).