при загрузке из сторонней ИБ последовательно получаются ИД документы и ИД номенклатуры.
в 1с в базе приемнике у справочника Номенклатура есть индексируемый реквизит ИД.
Сейчас поиск происходит через НайтиПоРеквизиту. (засунуть все ид из источника в тз и сделать в запросе соединение со справочником нет возможности).
Замер производительности показал что НайтиПоРеквизиту - самый длительный по времени.

Вопрос. Будет ли быстрее, если предварительно ссылки на номенклатуру и их ИД помесить в таблицу значений и в дальнейшем заместо НайтиПоРеквизиту использовать НайтиСтроку?
Или допустим все поместить в соответствие (ИД - ключ) и так же получать из соответствия?

поидее в случае с коллекциями - работа будет происходить с памятью, а не с многократными считыванием данных из ИБ? размер справочника примерно 50т. элементов оперативной памяти вагон.

может и быстрее... хотя если строк в загрузке немного то простая загрузка 50К элементов в ТЗ/соответствие займет больше времени чем поиск по реквизиту
(засунуть все ид из источника в тз и сделать в запросе соединение со справочником нет возможности - почему? - даже если например дважды источник прочитать?)

У меня в соответствии. В регистре соответствия ИБ приемника и ИБ источника хранится, первый раз идет поиск по регистру и потом в соответствие.

нет бы юзать РС, как все делают...

Делай через кэш, если в кэши не  нашел, тогда НайтиПоРеквизиту + добавить в кэш

(3) а какая разница?

(5) в РС тупо меньше данных и индексировать его можно только по колонке ИД из дальней базы. да и делать доп реквизит в типовой я б не стал (кстати в типовых, ЕМНИП регистр и так есть). А искать лучше получив целиком ТЗ из той базы, а потом подцепив к ней левым соединением данные этой (не важно, в РС они или реквизитом в справочнике). НайтиПоеквизиту или по коллекции в цикле - не лучший вариант.

(4) а как добавить в кэш?

З.Ы. не факт что у меня товары по несколько раз считываются. вполне возможно что все ИД встречаются по одному разу за весь обмен... и тогда поидее этот вариант выхлопа не особо даст

(6) да я понимаю что тз и соединение самое оптимальное, но идет считывание хмл, и предварительно я получить ТЗ не могу.

(7) кэш - это соответствие, если в соответствии не нашел, то ищи по реквизиту. Но если у тебя встречаются по одному разу, то без разницы.

(9) а если все-таки сразу поместить весь справочник в соответствие?

(8) что мешает преобразовать XML в ТЗ?

(11) в группу ТЗ, если идет загрузка документов с их таб частями...

(10) делай, как я говорю - будет профит

(10) Разумеется, поиск в соответствии самый быстрый. Вроде даже быстрее чем в индексированной таблице значений, не говоря уже об обращении к бд.
Но тут долгий процесс как раз инициализация этого соотвествия

http://www.nashe1c.ru/materials-view.jsp?id=212

к вопросу о кэше - в 8.2 можно сделать общий модуль, который будет автоматом кэшировать возвращаемые значения функций для набора параметров и если там поместить функцию, которая бы искала через НайтиПоРеквизиту или лучше через запрос в таком модуле - то поиск будет осуществляться 1 раз, а потом будет сразу отдаваться резуьлтат. Причем вполне возможно это будет быстрее, чем использование 1совских коллекций для кэширования

(16) Не факт. Каждый раз параметры разные, а значит и кэша не будет

(11) т.е. первый раз пробежаться по хмл и получить номенклатуру в ТЗ, а потом снова пробежать по хмл и выполнить уже стандартный механизм?

(14) аха, попробую затестить время инициализации соответствия.


(16) О! а ведь точно! Но опять же, это сработает если большая часть ИД будет повторяться. Если же они будут уникальны - то выхлопа не даст

переделал недавно поиск через соответствие... когда его размер достиг 200К элементов и все это дело надо было переезжать на клиента еще - документ в 10 строк грузился 5 минут

(17) ну, хочешь - помести справочник в индексированную ТЗ заранее. только это помещение будет сотни времени съедать. Правильнее сделать вообще без циклов, через (6)

(18).1 нет, загрузить весь XML в ТЗ или несколько (по количеству ТЧ документов + шапка) (грубо - то, что ты получить должен в итоге), потом эти ТЗ загрузить в запрос и в нем к ним массово прилепить данные из своей базы. Если что-то не нашлось - там да, надо будет подцепить отдельно.
(18).3 будет не медленнее, чем просто поиск по реквизиту, но без начальной инициализации... Надо смотреть, насколько данные будут повторяться в любом случае

Аха, спасибо за подсказки. Сейчас попробую для начала запрос к справочнику с полями ИД и Ссылка выгрузить в ТЗ и проиндексировать, и уже в ней искать через Найти.
следующий будет НайтиПоРеквизиту в хешируемом модуле

(17) Даже не в тз а в масссив. И делай запрос на вхождение реквизита в этот массив. Запихивай в соответствие.

(0) я пробовал и так и эдак. Искал по коду, SQL2005, платформа была 8.1. Таблица значений дала прирост в овер 700%.
Причем я даже так сделал: у меня был набор ТЗ, в которых хранились индексированные ссылки. Я сначала искал в ТЗ, если не находит уже делал НайтиПоКоду.

Лепил через соответствие. Ускорение было заметно даже на глаз.
А Свин меня удвиляет... Это не флейта...

(25) чем удивляю?

(26) тем, что эта тема поднималась на форуме неоднократно. И мной в том числе.
А поиск вроде как ещё работает.

(27) ну да. чет ступил. обычно 90% поиском нахожу. а тут чет не догадался.

Не понимаю, чем вас так удивил Нуф-Нуф

Вполне нормальный вопрос с ЕГО стороны. Ожидаемый.

(29) твой пост тоже не стал сюрпризом :)

аккумулировал ваши советы, реализовал так:
в начале получаю таблицу, индексирую ее, потом при необходимости ищу в ней соответствие по ИД через хешируемый общий модуль :)
буду тестить результат

(31) Куевый вывод

Ищем в индексированной ТЗ
Нашли - профит
Не нашли - ищем в базе
Дописываем в ТЗ
Профит

(33) если большая часть ИД в обмене уникальна - профита никакого, смотри выше

тем более что инициализация соответствия выполняется за секунды. никакие запросы к иб в виде найтипореквизиту уже не требуются

так что извини чувак, поднять свою самооценку тебе сегодня не получится

(34) Со справочником такое катит, а вот если у тебя План обмена ползает - куй.
1) Памяти не хватит
2) Фиг знаешь, что понадобится.

(36) Если совсем прижмет - забаню. Но пока терпит.

(37) если бы у бабки были яйца, она была бы дедкой

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

+(40) в основном для того, чтобы не становиться объектом удовлетворения для других

(34) на практике (24) профиту было, хоть *опой жуй

(42) а ты ТЗ сразу инициализировал? или накапливал походу работы обработки через НайтиПоКоду?

Девочки, не ссорьтесь

(43) я гляжу у тебя серьезный опыт работы в службе поддержки - ты читаешь только первую строку. В (24) написано, что ТЗ набиралась по ходу пьесы. При этом аналитика была почти без бублей

(44) ага, тока из всех собравшихся женский ник только у тебя, еслихчо...

(45) "у меня был набор ТЗ, в которых хранились индексированные ссылки", у меня как бы тоже набор в ТЗ :) только сразу

(47) пробовал сразу всасывать всё в ТЗ, на всасывание и индексирование чуть больше времени уходило в итоге, а памяти при этом уходило в разы больше - меня жаба задавила

почему сразу ко всем данным не прилепить ИДы?

вернее ссылки?

(0) Я вот сейчас сам озадачился переносом из семерки в восьмерку и решил сделать в 7 ке поле ref в каждом переносимом виде справочников и документов записывая в это поле УникальныйИдентификатор получая например по оле.
И создав описание Схемы опять же через Оле записывать в объекты в XML файл. При этом подходе не нужно ничего искать
когда в документах нужно прописывать ref справочников, документов