Сегодня опять рефакторил свой код под xCode, под MacOS X.
В части потребления памяти.
В некотором смысле в продолжение поста - Коротко. Об оптимизации потребления памяти под xCode. Затравочка.
(Почему вообще на Mac, а не наWindows? Ну потому, что там используются специфические маковские структуры, которые лучше всего обрабатыватся нативными маковскими библиотеками. Можно и на Windows перепортировать. Но это - потом. Залезая "в кишки".)
Определённых успехов удалось добиться.
Съэкономил 20% памяти на одних и тех же прецедентах.
С 200 Мб в пике до 160 Мб.
Вся суть в том, чтобы не "выливать воду из чайника" и "не использовать швейцарских ножей".
В общем - был класс генератора файлов, который одновременно генерировал в два формата.
Ну так было нужно изначально. В том ТЗ под который этот класс писался.
Потом появилось новое ТЗ, не исключающее предыдущего, но в нём не надо было генерировать один из форматов.
Ну собственно изначально взяли и использовали тот класс, о котором я писал выше.
Просто из результатов его деятельности использовали не два формата, а один, а другой просто - игнорировали.
В общем - брали "швейцарский нож" и "выливали воду из чайника" и сводили задачу к предыдущей.
До поры до времени это было некритично.
Потом - стало критично.
Скажем так - к этому прецеденту предъявляются "серверные требования". А не "десктопные".
Ну в итоге этот класс был распилен на три - один абстрактный предок и два конкретных потомка. Один конкретный потомок выливает один формат. Второй - оба формата. Ну и абстрактный класс - обеспечивает инфраструткуру. Можно конечно сделать три конкретных класса -для одного формата, для второго формата и для обоих. Но такой задачи - пока не стоит. Пока в ТЗ нет такого прецедента.
Можно было бы вообще использовать шаблон проектирования Builder или Strategy, но пока - опять же - это не нужно. Не стоит задача большой универсализации.
Был потрачен рабочий день и получено сокращение потребления памяти на 20%,
В общем - я лично доволен. День прошёл с пользой.
Да, ещё один немаловажный момент - это то, что тесты показали, что ошибок в конвертацию данных внесено не было. По крайней мере на текущих массивах данных. Ни одного расхождения.
Детали кода - писать лень. Всё равно - "синтетический пример" - вряд ли кому интересен.
Да и знатоки Objective-C это всё вряд ли читают. А переписывать пример на Delphi - тем более он переписывается "один в один", без потери эффективности. Я кое что писал - Objective-C и Delphi.
P.S. Это к не тому, что не надо вообще "выливать воду из чайника" и использовать "швейцарские ножи". Но к тому, что эти два анти-паттерна - служат первыми кандидатами на анализ проблем (Улучшение существующего кода, Что такое анти-паттерны?).
В части потребления памяти.
В некотором смысле в продолжение поста - Коротко. Об оптимизации потребления памяти под xCode. Затравочка.
(Почему вообще на Mac, а не наWindows? Ну потому, что там используются специфические маковские структуры, которые лучше всего обрабатыватся нативными маковскими библиотеками. Можно и на Windows перепортировать. Но это - потом. Залезая "в кишки".)
Определённых успехов удалось добиться.
Съэкономил 20% памяти на одних и тех же прецедентах.
С 200 Мб в пике до 160 Мб.
Вся суть в том, чтобы не "выливать воду из чайника" и "не использовать швейцарских ножей".
В общем - был класс генератора файлов, который одновременно генерировал в два формата.
Ну так было нужно изначально. В том ТЗ под который этот класс писался.
Потом появилось новое ТЗ, не исключающее предыдущего, но в нём не надо было генерировать один из форматов.
Ну собственно изначально взяли и использовали тот класс, о котором я писал выше.
Просто из результатов его деятельности использовали не два формата, а один, а другой просто - игнорировали.
В общем - брали "швейцарский нож" и "выливали воду из чайника" и сводили задачу к предыдущей.
До поры до времени это было некритично.
Потом - стало критично.
Скажем так - к этому прецеденту предъявляются "серверные требования". А не "десктопные".
Ну в итоге этот класс был распилен на три - один абстрактный предок и два конкретных потомка. Один конкретный потомок выливает один формат. Второй - оба формата. Ну и абстрактный класс - обеспечивает инфраструткуру. Можно конечно сделать три конкретных класса -для одного формата, для второго формата и для обоих. Но такой задачи - пока не стоит. Пока в ТЗ нет такого прецедента.
Можно было бы вообще использовать шаблон проектирования Builder или Strategy, но пока - опять же - это не нужно. Не стоит задача большой универсализации.
Был потрачен рабочий день и получено сокращение потребления памяти на 20%,
В общем - я лично доволен. День прошёл с пользой.
Да, ещё один немаловажный момент - это то, что тесты показали, что ошибок в конвертацию данных внесено не было. По крайней мере на текущих массивах данных. Ни одного расхождения.
Детали кода - писать лень. Всё равно - "синтетический пример" - вряд ли кому интересен.
Да и знатоки Objective-C это всё вряд ли читают. А переписывать пример на Delphi - тем более он переписывается "один в один", без потери эффективности. Я кое что писал - Objective-C и Delphi.
P.S. Это к не тому, что не надо вообще "выливать воду из чайника" и использовать "швейцарские ножи". Но к тому, что эти два анти-паттерна - служат первыми кандидатами на анализ проблем (Улучшение существующего кода, Что такое анти-паттерны?).
Комментариев нет:
Отправить комментарий