| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Общие вопросы > Замена if else |
| Автор: chip_and_dayl 3.8.2012, 12:51 | ||
| Всем привет. В коде есть следующее ветвление ifов
Так как этот код вызывается очень часто, то затормаживается работа программы. Как можно это ускорить/оптимизировать? |
| Автор: Akella 3.8.2012, 13:05 |
| все должны угадать, что там живёт в Create? Добавлено через 54 секунды Если код вызывается очень часто, то создай всё один раз, но не показывай. В нужный момент просто показывай/прячь. |
| Автор: chip_and_dayl 3.8.2012, 13:16 |
Проблема именно в if, поэтому в креейт смотреть не нужно. Вызывается очень часть, каждые 10 секунд и может вызваться от 1 до 200 за каждый вызов. Создать один раз не могу Добавлено через 8 минут и 54 секунды result: TfrmAbstractFrameCard Соответственно все объекты которые создаются, есть наследники TfrmAbstractFrameCard |
| Автор: XperT 3.8.2012, 13:30 | ||
Проблема не в if, он не может тормозить программу больше, чем создание формы, но если так сильно хочется его заменить на что-то более быстрое, то рекомендую посмотреть в сторону этой функции:
|
| Автор: Qu1nt 3.8.2012, 13:30 |
| http://www.gunsmoker.ru/2008/10/x-y-z.html |
| Автор: XperT 3.8.2012, 13:31 |
| Так же, если у вас все формы имею одного наследника, то можно посмотреть в сторону TDictionary |
| Автор: DarkProg 3.8.2012, 14:13 |
| Пробежавшись по коду могу предложить такой вариант оптимизации: 1. Регистрируете классы при запуске программы(REgisterClass) 2. При вызове функции делаете всего лишь FindClass, далее приводите к требуемому базовому классу и выполняете Create http://delphiworld.narod.ru/base/string_create_form.html |
| Автор: XperT 3.8.2012, 16:32 | ||||||
Посыпаю голову пеплом, но я больше чем уверен, что заменив ифы на что-то более оптимальное автор не добьется увеличение скорости, потому что явно проблема в другом. |
| Автор: baldina 3.8.2012, 16:50 | ||
| походу там просто очень много if и тормозит именно линейный просмотр ТСу нужен выбор более эффективный, чем O(n) альтернативы - дерево O(log(n)) и хеш-таблица O(1) TDictionary<keyT,valueT>, как я понимаю, хэш и есть
наверно даже если не имеют: в качестве valueT можно взять структуру из указателя на член-функцию и самого объекта, TMethod см. http://forum.vingrad.ru/topic-21991.html |
| Автор: Frees 3.8.2012, 17:46 |
| codeView откуда? Можно сдеалать одну процедуру которая принимает класс формы (а не имя класса) и создает ее как Application.CreateForm Можно еще GoF Порождающие шаблоны проектирования полистать. |
| Автор: baldina 4.8.2012, 00:12 |
проблема не в сокращении кода или изяществе, а в трудоемкости выбора. возможно, значительная переделка проекта позволит вообще избежать этого узкого места, но по умолчанию предполагается, что ТС не дурак и ему нужен ответ на его вопрос, а не констатация убогости его решения. |
| Автор: northener 4.8.2012, 00:33 | ||
Хм. Представьте реальный проект с таким узким местом и я с вами соглашусь |
| Автор: baldina 4.8.2012, 01:07 |
любой проект, где входные данные в виде строк должны отображаться на функции их обработки. синтаксический анализатор, если угодно. |
| Автор: Frees 4.8.2012, 10:13 | ||
Неизвестно откуда приходит эта строка, и есть ли возможность заменить строку с именем класса заменить на класс. |
| Автор: Чучмек 4.8.2012, 12:35 | ||
Ну вот можно сделать по аналогии
|