AXSerializer (DSPIC): вопросы

[mazzy]

Цитата:

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

Вот готовый проект сериализации\десериализации JSON\XML, на базе Newtonsoft.Json. Попробуйте, сравните. Как раз реализуется концепция "за счёт создания структуры классов, соответствующих структуре получаемого JSON, и прямая десериализация". Но скорость обработки от этого не зависит.

...

В общем попробуйте - расскажите по скорости и в целом, как оно.

Вложение 13253

Прежде всего, огромное спасибо за проект!

можно вопросы?

1. AXSerializer использует рефлекшн, чтобы получить название парм-методов. Рефлекшн в аксапте - медленный. что с производительностью?

2. AXSerializer кэширует инфо о классах в infolog.globalCache. Каков обычный размер кеша для обычного инстанса него и что со сборкой мусора, когда в перманентном кэше столько объектов?

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



4. вижу что у парм-методов первой строкой что-то вроде атрибута метода. но не понял как этот псведо-атрибут используется в проекте. можешь рассказать что это, где и как используется?

5. тебе не кажется, что предположение о parm-методе слишком жесткое? может стоило разбирать тип возвращаемого значения и типы параметров метода? все равно ж далее по коду они анализируются.



6. вижу, что коллекции - это тольео List и Array. Почему нет Set, Struct? и почему не потомки? (== вместо is). И почему не контейнер? это просто так исторически сложилось или ограничение движка? а какое?



Upd:
7. И да. На что бы ты сам посоветовал обратить внимание в проекте?

-------------

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

еще раз спасибо!

[DSPIC]

Цитата:

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

1. AXSerializer использует рефлекшн, чтобы получить название парм-методов. Рефлекшн в аксапте - медленный. что с производительностью?

Наверное, не так быстро, если бы это был не рефлекшен. Но я не тестировал, в моём случае нагрузка не высока.

Цитата:

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

2. AXSerializer кэширует инфо о классах в infolog.globalCache. Каков обычный размер кеша для обычного инстанса него и что со сборкой мусора, когда в перманентном кэше столько объектов?

А как измерить размер кэша? В кэше список методов класса-контракта и соответсвующие им названия пропертей в XML\JSON. Чем больше контракт тем больше кэш. Мусор убираю не я, но должен сам читститься по прекращению сессии, что эквивалентно сеансу обмена. Не проверял - не интересно, не думаю что это проблема.

Цитата:

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

2. AXSerializer кэширует инфо о классах в infolog.globalCache. Каков обычный размер кеша для обычного инстанса него и что со сборкой мусора, когда в перманентном кэше столько объектов?

Цитата:

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

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

Всё верно. Исключительно для подсказки сериализатору - какого типа объект в списке. Хочется это запихнуть в псевдо-аттрибут (макрос сверху метода), но т.к. этот макрос, по сути просто комментарий, то а) в случае неверного написания не получим compilation error б) не увидим использование этого типа в CrossRef

Цитата:

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

4. вижу что у парм-методов первой строкой что-то вроде атрибута метода. но не понял как этот псведо-атрибут используется в проекте. можешь рассказать что это, где и как используется?

Это и есть аттрибут, в моём исполнении для AX2009. Сериализатор сканирует все поля контракта на предмет наличия этого аттрибута, тем самым понимая, какие поля нужно сериализовать и извлекает названия этих полей. Эту информацию он заталкивает в мапу и кэширует, чтобы не сканировать source code повторно. Вероятно, следовало бы макрос сделать чуть более похожим на настоящий атрибут в AX2012, с точки зрения синтаксиса, дополнив возможность указывать тип ы коллекций или просто тип, но см. п.3 выше.

Цитата:

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

5. тебе не кажется, что предположение о parm-методе слишком жесткое? может стоило разбирать тип возвращаемого значения и типы параметров метода? все равно ж далее по коду они анализируются.

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

Цитата:

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

6. вижу, что коллекции - это тольео List и Array. Почему нет Set, Struct? и почему не потомки? (== вместо is). И почему не контейнер? это просто так исторически сложилось или ограничение движка? а какое?

List и Array вполне хватает. Даже одного List хватает. Если же тему развивать, то почему бы туда не добавить возможность сериализовать, скажем, FormRun, разложив её вплоть до пропертей контролов?

Цитата:

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

7. И да. На что бы ты сам посоветовал обратить внимание в проекте?

Что я там не дожал в части XML - это продумать\привести в порядок названия узлов. Сейчас там можно встретить такие методы, как GetElementName, GetRootName. С одной стороны - это опять же можно воткнуть в аттрибуты. С другой стороны - хотел, чтобы сериализатор работал со стандартным AIF AX2009 (Если помнишь, стандарт умеет серилизовывать только Document-Services, когда как для CustomServices правила сериализации и XSD приходится хардкодить самому, что то ещё удовольствие). Так вот GetElementName\GetRootName нужны именно для AIF + все мои контракты наследуются от XMLSerialisable, что опять же нужно для AIF. В результате - эту чуть нужно бы проверить\пересмотреть. На чём я там остановился - уже не помню.
Да, XSD этот проект тоже генерит. Но помнится не всё типы поддерживаются, т.к. я отлаживал только то, что мне было нужно.

Что ещё: нужно было бы избавиться от классов-контрактов типа *List. Они избыточны. Т.е. достаточно в аттрибуте укуазать, что это будет List такого-то типа.

Цитата:

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

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

С удовольствием передам тебе это право.

[mazzy]

Спасибо.

Цитата:

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

Но я не тестировал, в моём случае нагрузка не высока.

ок. понял.

Цитата:

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

А как измерить размер кэша?
не думаю что это проблема.

хотя бы число элементов в кэше.
особенно по сравнению с кэшем АИФа.
ок. понял.

Цитата:

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

Всё верно. Исключительно для подсказки сериализатору - какого типа объект в списке. Хочется это запихнуть в псевдо-аттрибут (макрос сверху метода), но т.к. этот макрос, по сути просто комментарий, то а) в случае неверного написания не получим compilation error б) не увидим использование этого типа в CrossRef

угу. про макрос понял.

Цитата:

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

List и Array вполне хватает. Даже одного List хватает. Если же тему развивать, то почему бы туда не добавить возможность сериализовать, скажем, FormRun, разложив её вплоть до пропертей контролов?

ну... я ж не ради увеличения.

тот же struct позволяет создавать именованные поля, не создавая классов.
тот же struct в CIL 2012 работает сильно быстрее чем остальные коллекции (из-за чего и используется в АИФе 2012)

Цитата:

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

Что я там не дожал в части XML - это продумать\привести в порядок названия узлов. Сейчас там можно встретить такие методы, как GetElementName, GetRootName.

ok

Цитата:

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

Так вот GetElementName\GetRootName нужны именно для AIF + все мои контракты наследуются от XMLSerialisable, что опять же нужно для AIF. В результате - эту чуть нужно бы проверить\пересмотреть.

ты ведь щас все еще про 2009 говоришь?
.

Цитата:

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

С удовольствием передам тебе это право.

спасибо.

тогда можно попросить тебя сделать простейшие начальные шаги:
1. выбери имя проекту и создай пустой проект на гитхабе (или гитлабе, или где тебе удобнее)
2. при создании выбери лицензию (типичная лицензия - MIT - разрешает пользователям любое использование и освобождает автора от ответственности за любое использование другими)
3. желательно, чтобы ты, как автор, написал какой-нибудь readme.md (можно в пару строчек, можно просто текст)

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

такой способ публикации оставит за тобой не только авторские права, но и "первородство" с точки зрения гитхаба

а дальше да, можно будет попробовать поизучать и попробовать что-то сделать с проектом.

------------
"Человеко-читаемый код" позволяет не только читать, но и делать ссылки на строки проекта. Например. А большой xpo-файл тот же гитхаб может начать показывать только в raw-режиме.