Оптимизация

[Alex_KD]

Навеяно последними разработками:

adkotov: Axapta Editor - Suggestions, Autotext, Hotkeys

Итак. Возможно ли ускорить данную операцию (аналогично для таблиц, енум, и ЕДТ):

static void Job1(Args _args)
{
    DictClass  dictClass;
    Dictionary dict = new Dictionary();
    int i = 0, j = 0;
    int counter;
    int      begin;
    ;
    begin   = WinApi::getTickCount();
    counter = dict.classCnt();
    for( i=1; i<=counter; i++)
    {
      dictClass = dict.classObject(dict.classCnt2Id(i));
      if(dictClass)
      {
        dictClass.name();
        //do something
      }
    }
    info(strfmt("Time = %1", WinApi::getTickCount() - begin));
}

Проблема в следующем: при первом запуске на "холодной" Аксапте загрузка идет 22с, следующие запуски 140-150 мс. Реально ли первую цифру максимально приблизить к 2й?
Пока вижу только 1 вариант - скидывать на диск список названий в какой нибуть файл (или БД) и использовать его. Еще есть варианты?

[kashperuk]

На самом деле, зависит от

//do something

потому что если нужно только имя, то можно попробовать использовать таблицу UtilElements - вроде как с ней должно быть быстрее

[Alex_KD]

Цитата:

Сообщение от kashperuk

На самом деле, зависит от

//do something

потому что если нужно только имя, то можно попробовать использовать таблицу UtilElements - вроде как с ней должно быть быстрее

Да, ты прав. "//do something" играет роль. Но тут Общее время = время ("//do something) + скорость Dict методов. Ускорим одно - ускорится общее.
В самом деле "//do something" - добавление элемента в массив (оч. быстро) + сортировка (средне).

[Alex_KD]

Кстати в UtilElements системные типы не попадают.
Например, класс MapEnumerator - нету там такого.

PS Время немного меньше. До 140-150 мс далеко...

[mazzy]

Цитата:

Сообщение от Alex_KD

Проблема в следующем: при первом запуске на "холодной" Аксапте загрузка идет 22с, следующие запуски 140-150 мс. Реально ли первую цифру максимально приблизить к 2й?

Нет.

Разве что таким способом http://axapta.mazzy.ru/lib/aoscash/
но кто-то должен будет следить за кэшем

Цитата:

Сообщение от Alex_KD

Пока вижу только 1 вариант - скидывать на диск список названий в какой нибуть файл (или БД) и использовать его. Еще есть варианты?

Не стоит.

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

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

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

Alex_KD, может быть стоит таки использовать стандартный кэш ядра?
А уменьшить время первоначальной загрузки сократив количество обращений к объектам?
Вариант 1: читать только включенные конфигурационными ключами объекты.
Вариант 2: читать только перечисленные в настройках приблуды объекты.
Вариант 3: работать по перекрестным ссылкам (но проблема одновременной работы нескольких программистов в этом варианте останется)
Вариант 4: разобраться как ядро работает с мастер-кэшем в разных сервис-паках и заставлять администраторов периодически обновлять его на программистских компьютерах.

Лично мне больше всего нравится четвертый вариант, так как он уменьшит количество кода в вашей доработке, а следовательно уменьшит и время "холодной" загрузки.

[mazzy]

Цитата:

Сообщение от Alex_KD

Кстати в UtilElements системные типы не попадают.
Например, класс MapEnumerator - нету там такого.

Как это нету, если AOT физически хранится в таблице UtilElements?
Другие способы работы с АОТ - это всего лишь другие представления этой таблицы, другие способы работы с этой таблицей.

[Alex_KD]

Цитата:

Сообщение от mazzy

Как это нету, если AOT физически хранится в таблице UtilElements?
Другие способы работы с АОТ - это всего лишь другие представления этой таблицы, другие способы работы с этой таблицей.

Боюсь там только то, что видно в АОТ в ветках Classes (для классов). MapEnumerator, Dict* классы - в таблице не находятся (открывал в TableBrouser и искал по name - нету). Еще количество записей из таблицы

select utilElements group by name
    where utilElements.recordType == UtilElementType::Class

и из dictionary.classCnt() - отличаются на пару сотен.

[Alex_KD]

Цитата:

Сообщение от mazzy

Нет.
Разве что таким способом http://axapta.mazzy.ru/lib/aoscash/
но кто-то должен будет следить за кэшем

Так не устраивает по понятным причинам - утилита должна работать сама по себе. А так получается надо напрягать пользователя-программиста-админа.

Цитата:

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

Насчет пол гига сильно сомниваюсь. ИМХО, 99% от этих "полгига" - это код методов и он не грузится в ДиктКлассах.
Проверю.

Цитата:

Может стоит подгружать по мере необходимости, а не делать свой кэш?

Неполучится. Мне надо знать какие обьекты есть в системе ДО того как программер начинает кодить. Чтобы понять, что QBDS - это QueryBuildDataSource надо сначала получить это имя (QueryBuildDataSource), затем распарсить до Акронима (QBDS). Если это делать в момент ввода - список подсказок будеть грузиться долго.

Цитата:

Вариант 1: читать только включенные конфигурационными ключами объекты.
Вариант 2: читать только перечисленные в настройках приблуды объекты.
Вариант 3: работать по перекрестным ссылкам (но проблема одновременной работы нескольких программистов в этом варианте останется)
Вариант 4: разобраться как ядро работает с мастер-кэшем в разных сервис-паках и заставлять администраторов периодически обновлять его на программистских компьютерах.

Вариант 1 и 2 - мысль полезная...очень даже. Не факт, что такой подход ускорит работу, но то, что Акронимы будут более полезны это 100% (что не используется, то не будет отображатся в cписке подсказок).
В варианте 4 мне не нравится "Заставлять администраторов". Если выбирать между "заставлять" и временем загрузки 1-2 мин, второе предпочтительнее.

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

И всетаки чем не нравится свой кэш?
1. Это файл размером ~200-300Кб. (надо ведь только названия).
2. Это ускорит загрузку - в своем "кэше" можно хранить данные в уже готовом виде (мне надо сортировать элементы).
3. Оставить синхронизацию в виде доп. кнопки, а не делать ее перед запуском.
Синхронизацию все равно надо - новые элементы не попадают.
4. Возможность усовершенствования Акронимов - была идея хранить историю использования и сортировать в списке подсказок опираясь на историю. Т.е. если часто используется тип InventTable - предлагать его первым по акрониму IT (актуально когда по акрониму предлагает кучу мусора, а то что реально используется где-то там в конце списка).

Минусы. Если возможно сделать синхронизацию за 5-20 сек., то лучше делать это принудительно перед запуском утилиты AxAssist.