Каковы накладные расходы на объектно-ориентированное программирование? - PullRequest
2 голосов
/ 16 декабря 2008

У меня большой набор данных (куб данных 250 000 x 1000, удваивается, около 4-гигабайтного файла), и я хочу манипулировать им, используя предыдущий набор классов ООП, который я написал на Python. В настоящее время набор данных уже настолько велик, что для считывания в память моего компьютера мне нужно, по крайней мере, разделить его пополам, поэтому вычислительные затраты являются проблемой. Мои классы ООП создают новые объекты (в этом случае мне понадобится 250 000 новых объектов, каждый объект представляет собой массив из 1000 двойных чисел) для обработки данных. Каковы накладные расходы с точки зрения памяти и вычислений, необходимых при создании объектов для общего языка ООП? В питоне? Как насчет C ++?

Да, я понимаю, что могу создать новый класс, который будет массивом. Но 1) я уже закончил эти классы и 2) я в любом случае помещаю каждый созданный объект обратно в массив для последующего доступа. Вопрос педагогический

* обновление: я хочу работать со временем, своим временем и компьютерами. Я не хочу переписывать программу, которая у меня уже есть, если мне не нужно, и трата времени на оптимизацию кода тратит впустую мое время, мне все равно , что , если я трачу время компьютера. У меня на самом деле есть 64-битная машина с 4Gig RAM. Данные являются изображением, и мне нужно сделать несколько фильтров для каждого пикселя. *

Ответы [ 14 ]

3 голосов
/ 17 декабря 2008

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

3 голосов
/ 16 декабря 2008

У вас могут быть похожие проблемы с процедурными / функциональными языками программирования. Как вы храните столько данных в памяти? Структура или массив также не будут работать.

Вам необходимо предпринять специальные шаги для управления таким масштабом данных.

Кстати: я бы не стал использовать это в качестве причины для выбора языка OO или нет.

2 голосов
/ 16 декабря 2008

См. http://code.activestate.com/recipes/546530/

Это приблизительный размер объектов Python.

"Штраф" размера ОО часто компенсируется способностью (а) упростить обработку и (б) в первую очередь хранить меньше памяти в памяти.

Производительность ОО не снижается. Нуль. В C ++ определения классов оптимизированы вне существования, и все, что у вас осталось, это C. В Python, как и во всех динамических языках, среда динамического программирования добавляет некоторые поиски времени выполнения. В основном это прямые хеши в словари. Это медленнее, чем код, где компилятор сделал все для вас. Однако это все еще очень быстро с относительно низкими издержками.

Плохой алгоритм в C может быть медленнее, чем правильный алгоритм в Python.

2 голосов
/ 16 декабря 2008

Я бы не посчитал справедливым обвинять какие-либо недостатки вашего дизайна в ООП. Как и любая другая платформа программирования, ОО может использоваться как для хорошего, так и для неоптимального дизайна. Редко это будет ошибкой самой модели программирования.

Но чтобы попытаться ответить на ваш вопрос: выделение 250000 новых объектов требует некоторых накладных расходов на всех языках ОО, которые мне известны, поэтому, если вам удастся избежать потоковой передачи данных через один и тот же экземпляр, вам, вероятно, будет лучше ,

1 голос
/ 17 декабря 2008

Фактические накладные расходы памяти C ++ OO - один указатель (4-8 байт, в зависимости от) на объект с виртуальными методами. Однако, как упоминалось в других ответах, накладные расходы на выделение памяти по умолчанию при динамическом выделении, вероятно, будут значительно больше, чем это.

Если вы делаете что-то на полпути разумно, ни одна служебная нагрузка вряд ли будет существенной по сравнению с двойным массивом 1000 * 8 байт. Если вы на самом деле беспокоитесь о накладных расходах, вы можете написать свой собственный распределитель, но сначала проверьте, действительно ли он принесет вам значительное улучшение.

0 голосов
/ 17 декабря 2008

Поскольку вы можете разделить данные пополам и работать с ними, я предполагаю, что вы работаете с каждой записью в отдельности? Для меня это звучит так, будто вам нужно изменить десериализатор так, чтобы он считывал по одной записи за раз, манипулировал ею и затем сохранял результаты.

В основном вам нужен класс парсера строк, который выполняет Peek (), который возвращает символ, знает, как пропустить пробел и т. Д. Оберните класс таким, который понимает ваш формат данных, и вы должны иметь возможность его выплюнуть объект за раз, когда он читает файл.

0 голосов
/ 17 декабря 2008

Мой друг был профессором в MIT, и один студент спросил его, почему его программа анализа изображений работает так медленно. Как это было построено? Каждый пиксель является объектом и будет посылать сообщения своим соседям!

На вашем месте я бы попробовал это в одноразовой программе. Я подозреваю, что если ваши классы не очень тщательно закодированы, вы обнаружите, что они тратят много времени на выделение, инициализацию и отмену выделения объектов, и, как сказал Брайан, вы могли бы спулировать данные через набор повторно используемых объектов.

Редактировать: Извините. Вы сказали, что повторно используете объекты, так что это хорошо. В любом случае, когда вы его запустите, вы можете профилировать его или (если вы были мной) просто прочитать стек вызовов несколько раз, и это ответит на любые вопросы о том, куда идет время.

0 голосов
/ 17 декабря 2008

Если вам приходится регулярно манипулировать такими массивами данных, не могли бы вы просто получить 64-битную машину с большим количеством ОЗУ? По разным причинам я обнаружил, что работаю с довольно ресурсоемким программным обеспечением (в данном случае SQL Server Analysis Services). Старые 64-разрядные машины такого типа могут занимать большие объемы оперативной памяти и иметь центральные процессоры, которые хотя и не являются передовыми, но все же довольно быстрыми.

Я получил несколько бывших в употреблении рабочих станций HP и оснастил их несколькими быстрыми дисками SCSI. В середине 2007 года эти машины с 4 или 8 ГБ ОЗУ и 5x 10К или 15К SCSI-дисками стоили от 1500 до 2000 фунтов стерлингов. Диски составляли половину стоимости машин, и вам может не потребоваться производительность ввода-вывода, поэтому вам, вероятно, не придется тратить так много. XW9300 того типа, который я купил, теперь можно купить на ebay довольно дешево - эта моя публикация содержит различные варианты использования ebay для получения высокопроизводительной 64-битной коробки на дешевый Вы можете получить обновление памяти до 16 или 32 ГБ для этих машин от ebay за довольно небольшую долю от цены по прейскуранту на запчасти.

0 голосов
/ 17 декабря 2008

Пожалуйста, определите "манипулировать". Если вы действительно хотите манипулировать 4 гигабайтами данных, почему вы хотите манипулировать ими, сразу вытащив их ВСЕ в память?

Я имею в виду, кому все равно нужно 4 гигабайта оперативной памяти? :)

0 голосов
/ 17 декабря 2008

по сравнению с размером вашего набора данных, накладные расходы 250K объектов незначительны

я думаю, что вы на неправильном пути; не вините в этом предметы; -)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...