Вопрос о байт-коде 1С #258579

Господа, вот если я в 1с пишу Для Инд=1 по 1000 цикл Скажите, каждый раз в цикле у объекта X ищется по наименованию в списке методов метод "Обработать" и вызывается, или же происходит как-то по другому?

Господа, вот если я в 1с пишу Для Инд=1 по 1000 цикл Скажите, каждый раз в цикле у объекта X ищется по наименованию в списке методов метод "Обработать" и вызывается, или же происходит как-то по другому?

2 Каждый раз ищется по наименованию.

опупеть! И что, даже если я пишу X.Print то тоже каждый раз по наименованию? Зачем, если я точно понял название метода - Print и тип объекта не поменялся?

Садовников, в IDispatch та же хрень, так?

Нда... Это и есть IDispatch.

2 Откуда ж системе знать, что тип объекта не изменился?

альф, если не вызывался деструктор, то и тип не менялся. Странный ты вопрос задал.

Ладно, альф, слушай сюда, вот есть точка кода, где вызывается X.Print, так, название метода зафиксировано в коде. Почему бы проге не сделать двумерный массив [Тип][номер Метода] чтобы по текущему типу сразу находить без поиска адрес метода, тогда только при загрузке нужно заменить имя Print на номер этого метода в глобальном списке названий методов. Вуаля, ё!

2 Какой деструктор? Гля сюда: х.Принт; // тут ошибка И для объекта "некийОбъект" никакого деструктора не вызывается, он все еще существует. Просто на него теперь ссылается другая переменная. Учи матчасть, а не старайся на своих домыслах строить "лучшие предложения". В 1С переменные не типизированы. 2 Тип переменной становится известен только в момент выполнения. При компиляции (или, как ты сказал "загрузке") модуля, тип еще неизвестен. А тем более неизвестны методы для этого типа.

Как то уже MMF исследовал этот вопрос:

альф, во первых ты не почитал почитай еще раз ВНЕМАТЕЛЬНО! Далее, если в точке кода x.Print запоминать тип объекта x, который был передан в прошлый раз, то можно повторно не искать. Это раз. А если ты соизволишь почитать еще раз то поймешь, что искать вообще не надо, достаточно двумерного масива!

А если в цикле ты подменил переменной тип после 125 итерации?

и что же, следуя 12, есть двумерный массив методов, примерно такой   X  Print  по адресу такому-то  Save   по адресу такому-то  Run    по адресу такому-то Y  Print  по адресу такому-то  Save   метода нет  Run    по адресу такому-то

я не знаю особенности твоего "языка программирования", но если ты сделаешь так что тогда?

здесь нет вызова методов, давай другой пример

a.print - вызовется метод print объекта X b.print - вызовется метод print объекта Y a=b a.print - вызовется метод print объекта Y a.save - выдастся ошибка - метода save нет у объекта Y

for i:=1 to 100 do begin  X.Print;  if i=10 then end;

никаких проблем, ведь тип объекта определяется на момент вызова метода Print, соответственно, пока тип X, будет вызываться X::Print, когда тип станет Y, будет вызываться Y::Print, посмотри еще раз на двумерную таблицу. Пусть тип X - это 1, тип Y- это индекс 2. Пусть print - это 6. Тогда когда мы вызываем X.Print, мы смотрим, какой тип в переменной X, пусть это будет X и вызываем метод, который находится в двумерном массиве в яцейке Methods[1][6] Если это тип Y то вызываем метод из ячейки Methods[2][6] Методов и классов в базе ограниченное число, не считая внешних обработок, то бишь получаем полный эрзац. Альф, ты не просек фишку, теперь должен признать, что это ГЕНИАЛЬНО!

А че виртуальная машина 1С уже в открытом доступе ?

а виртуальные методы попрут?

ну можно нуралиеву написать, пусть УСКОРЯЕТ. Ведь факт прироста скорости интертрепатора - налицо

все попрет, любой объект 1С имеет ограниченное число методов. массив будет скажем размером 200*500 элементов, это слезы, я вас умоляю, зато прирост в скорости - на порядок!

2 Конечно, гениально.

то то же, господин Сольери, ладно, я отчалил

Осталось только за компилятором

2 Скорости чего?

ну не знаю, будет ли Нуралиев оптимизировать интертрепатор... Хотя нахаляву прирост быстродействия в 10 раз (в среднем сколько методов у одного объекта), никому не повредит. ;-)

быстродействия интертрепатора, конечно же

2 Аааа... Ну-ну...

мдя, интересное отношение сообщества - я предлагаю им способ ускорить быстродействие интерпретатора на порядок (10 раз), проверили, действительно ускоряется скорость, но сообчеству пофиг. Интересно, почему такая апатия?

сделай поиск по слову "TurboBL"

2 Просто неинтересно тебе прописные истины объяснять. Разберись для начала в механизме работы интерпретатора 1С, тогда можно будет продолжить разговор. А на твои "вот если бы" смысла отвечать нет.

где код проверки?

Напишеш программу тогда обсудим

гыгыгы, я умный, вы - дурак? Ну вы хотябы мне идиоту намекните. вместо 88 поисков будет 1. Вот это я называю - на порядок. Какой код проверки! я не занимаюсь системным программированием. Ну и что? Турбо БЛ каждый раз при вызове ищет номер метода, я же предлагаю найти его один раз, при компиляции модуля. Вот про BL: КРАТКИЙ ЭКСКУРС В МЕХАНИЗМ ВЫЗОВА МЕТОДОВ. ДЛЯ ВСЕХ Что происходит внутри 1С, когда мы пишем спр.ТекущийЭлемент? 1С преобразует имя метода ТекущийЭлемент в соответствующий ему номер, и вызывает метод объекта по номеру. НО, клинические исследования показали, что для ЛЮБОГО объекта 1С используется один алгоритм такого преобразования, реализованный "В ЛОБ", и котрый заключатся в простом последовательном переборе всех имен методов объекта и сравнении их с искомым. Соответственно, чем больше номер метода, тем большее время занимает такой поиск. Например, для того же "ТекущийЭлемент" перед реальным вызовом функции происходит перебор 88 названий методов. Аналогично и для свойств объектов. ДЛЯ ЗНАКОМЫХ С "RAINBOW" Как известно, для поиска номера метода применяется virtual int CBLContext::FindMethod(const char* name); Как оказалось, НИ В ОДНОМ из объектов 1С данный метод не переопределен. Перехват вызова функций различных объектов показал лень и мягко говоря, не вполне компетентность людей, писавших этот код. Вобщем, когда вызывается FindMethod, из него вызываются: GetNMethods, GetMethodName(i,0), GetMethodName(i,1) т.е. FindMethod работает примерно так:         Понятно, хотелось добиться универсальности и простоты, что и достигнуто. Но при этом: Некомпетентность: GetNMethods можно вынести из цикла. Лень: не зря же FindMethod виртуальная, почему же она не переопределена ни в одном из наследуемых классов для более оптимального поиска? Аналогичная ситуация и с FindProp.

напиши, в чем я не прав.

2 Тебе же сказано было: переменные в 1С не типизированы. Это значит, что до момента выполнения ты не знаешь тип переменной и, соответственно номер метода ты никак не получишь. Что тут непонятного?

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

а может я просто невнятно излагаю, если надо, поясню еще раз

2 Откуда ты знаешь номер мето, не зная типа? Ты читать умеешь? Для совсем уж гениальных:

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

т.е. когда будет вычисляться ТекущаяСтрока, при загрузке в этой точке кода сохранен номер метода ТекущаяСтрока - 15, осталось только взять текущий номер типа (тип содержит номер), в первом случае это будет 1, во втором 20 и вызвать метод по адресу [1][15] или [20][15]

2 Мда... И ты считаешь, что твое дерево из возможных методов будет работать быстрей, чем просто поиск по имени? Мда...

+ Вспомни еще, что в момент компиляции движок совсем не обязан знать о всех возможных типах, которым этот метод может принадлежать. Это намек на ВК и ActiveX, если ты не понял.

Гений, как та сова из анека: - Мышки станьте ежиками! - А как?! - Я тактикой не занимаюсь! Я - стратег!

Альф, не тупи, это не дерево, это массив!!!!

ВК, АктивХ и внешние обработки пусть работают по старому, вопрос касается ускорения типового функционала.

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

2 Рекомендую тебе хоть раз просто подумать, прежде чем постить. Или тебе нравится выглядеть полным идиотом?

Идиотом, может быть и нет, но поглумиться ему явно нравиться :)

давайте по существу. Итак, у нас есть двумерный массив, скажем 200 методов на 200 классов, итого 40 000 адресов. Какие проблемы?

40 Килобайт - цена вопроса. Даже мегабайта нет.

Предлагаю не спорить а подождать хотябы действующий прототип программы от Гения 1с

Ты думаешь дождемся?

2 По какому существу? Ты вот сам для себя распиши хотя бы простейший модуль по своей "схеме".

Кстати, ты правда думаешь что такой костыль кто будет массово использовать? Например, функциональность 1С++ мало кто испльзует поскольку, банально, не знает и боится. Даже функционал такой красивой ивкусной штуки как открытый конфигуратор народ боиться использовать массово.

без практики грош цена таким заумствованиям

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

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

2 Тебе уже сказано, что "нет" и объяснено почему.

не объяснено. Про то, что неизвестен тип - я объяснил что это не так. что не ясно?

АЛьФ, не обращай внимания. Не все идеи Гения 1С разумны... У нас в институте один генератор идей предлагал клеить бумагу с помощью обычного ксерокса :) Эта идея того же порядка.

Звездочет, я могу разумно объяснить почему нельзя клеить бумагу обычным ксероксом. Давай теперь ты объясни, почему этот метод ускорения не взлетит, или только потрепаться силен?

2 Я тебе тосно говорю, что на этапе компиляции ты не имеешь понятия о типе. И максимум что можешь получить - дерево с возможными вариантами типа для этапа выполнения. Оптимальности это ни какой не даст. И память будет лопаться по экспоненте. Думай. 2 Я знаю. Просто у меня сейчас идет тестовое проведение 20000 документов. Надо как-то развлечься :)

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

у меня уж было возникло желание предложить свой взгляд на проблему, но я подумал, что знаний в этой области у АЛьФа на порядок выше. Он и так уже все скзал. Зачем базар устраивать? :)

Итак. у нас есть двумерный массив methods Первое измерение - номер метода, второе измерение - номер типа. Также есть массив methods_names, содержащий названия методов. Допустим method_names выглядит так: Допустим мы загружаем модуль документа и такой код: И в точках кода, где есть вызов метода будут храниться номера методов - в тексте они в  фигурных скобках. Далее, когда программа доходит до точки кода, где сохранен номер метода, она обращается к двумерному массиву, берет номер типа объекта (он хранится в типе объекта) и извлекает адрес процедуры, затем вызывает ее. Что непонятно, куда еще подробнее?

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

2 Номера методов в фигурных скобках ты для какого типа привел? Или ты допустил, что у всех типов одинаковый набор методов?

посчитаем размер массива. ОК. Число различных методов у различных объектов - например пусть 1000 методов. Число типов объектов (УПП, например) - 500. Итого размерность 500 000 элементов. Допустим, всего в базе 500 объектов * 200 методов у каждого = 100 000 процедур или в шестнадцатеричной системе 186A0, т.е. для номера процедуры нужно всего 4 байта. итого это 2 млн байт или 2 мегабайта - вот такая цена за ускорение интерпретатора в 10 раз. Почему в 10 раз? да потому что методов у объекта в среднем 20-100 штук, следовательно даже с использованием BPL вместо поиска в массиве 20-100 элементов, даже с эффективностью log2N используется непосредсвенный выбор значения из массива, т.е. эффективность порядка 1 действие!

есть глобальный список методов. Это номер метода в глобальном списке методов

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

меня интересует - моя теория верна или нет. Если так в 8.1 - чудненько, но если не так, то есть еще куда ускорять. тут будет конструктив или только понтоваться будем?

Ну и напиши сам - дольше споришь, нежели до сути докапываешься.

что написать, блин, что написать? Речь идет не о программировании, а о концепции. Я не могу написать, ибо нужно вмешаться в код платформы. 1С не open-source. Речь о том, чтобы передать эту ботву в 1С, если теория правильная. Не надо предлагать мне НАПИСАТЬ!

или ты не умеешь размышлять теоретически? Чистый Практик, что ли?

Передай в 1с. В чем проблема?

2 "Глобальный список методов" - это методы глобальных контекстов и глобального модуля. К ним обращение и так идет по номеру.

Суха теория мой друг, он древо жизни зеленеет

2 Да кому он там нужен? Это мы тут ему что-то пытаемся объяснить, а там просто похихикают и даже отвечать не станут. Думаешь им мало таких опусов приходит? :)

Глобальный список методов - это список различных названий методов, которые встречаются в конфе у объектов. Так понятнее?

чтобы что-то объяснить, нужно сначала понять, а с этим проблемы...

2 И как это список связан с реальным номером метода определенного типа?

конечно же через двумерный массив. после компиляции в точках кода расставлены номера методов. На этапе исполнения мы знаем номера типов. нужно только взять из двумерного массива значение из ячейки с номером метода и номером типа. Все ГЕНИАЛЬНО и ПРОСТО.

Мда..Perpetum Mobile говориш

яя. По ходу альф только счас понял, о чем речь. Видимо, думает

2 У тебя в массиве порядковые номера из общего списка. Как они связаны с номерами методов типов? 2 Знаешь ли, я твои ветки не мониторю еже секундно. Не обольщайся.

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

2 Еще раз: ты не знаешь и никогда не узнаешь типа на этапе компиляции, т.к. в 1С переменные нетипизированы. Неужели так сложно осмыслить этот простой факт? Если ты возьмешься на этапе компиляции прописывать для каждого метода все возможные типы, то у тебя получится дерево, которое будет расти по экспоненте.

альф, ну ты тупишь. На этапе компиляции у меня есть конфа и я знаю все типы. Это (для восьмерки): ссылки и объекты справочников, документов и т.п. строки определенных табличных частей прикладных объектов наборызаписей, менеджеры и т.п. регистров. Т.е. список этот фиксированный. Для ОЛЕ, АктивИск, и т.п. не используем оптимизацию. что, поспоришь?

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

Говорят в 8.1 произвели оптимизацию компилятора

Ладно, я до дому, надеюсь альф объяснит внятно, где он экспоненту нашел. ;-)

2 Ну... я сделал все, что мог... Пытаться убеждать твою ДНК выстроиться в правильном порядке не буду... это еще более напрасный труд...

100!

100! То бишь сдался ты Альф... Надеюсь ты хоть вьехал в то, что пытался опротестовать

блин

напоследок - Альф,  где ЭКСПОНЕНТА?