Как быстрее, передать подпрограмме указатель на объект или ..

← →
TStas © (2005-08-08 19:48) [0]

Что будет работать быстрее в программе с интенсивным счетом, подпрограмма, которой передается указатель на объект или метод объекта? Вообще стоит ли при интенсивном счете создавать объекты, или использовать записи и функции, которые принимаю записи (указатели на записи)?

← →
Юрий Зотов © (2005-08-08 19:57) [1]

Реальные адреса виртуальных и динамических методы сначала ищутся по таблицам, поэтому они срабатывают медленнее, чем статические методы и просто процедуры/функции.

Создание объекта - это выделение памяти и ее инициализация. На это тоже тратится время.

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

← →
Суслик © (2005-08-08 19:59) [2]

ты лучше спроси, приведя конретный код.

А вообще - проведи опыт, и сравни время. Это будет точнее всего.

← →
Суслик © (2005-08-08 20:00) [3]

> [1] Юрий Зотов © (08.08.05 19:57)

на самом деле не очень понятно о чем автор спрашивает.

Что значит использовать записи? Из стека брать или динамически создавать. Пример бы, точнее ответить можно.

← →
TStas © (2005-08-08 20:04) [4]

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

← →
Наиль © (2005-08-08 20:06) [5]

Если данные которые ты хочешь передать, уже находятся в памяти, то передавай только указатель на начало. Для файла - передай имя. Если нужно передать метод обработки, то передавай только функцию (без объекта, её содержащюю).

← →
TStas © (2005-08-08 20:22) [6]

Данные должны динамически создаваться и в процессе своей обработки создавать новые, образуя древовидную структуру. Вот и думаю, или делать запись с указателями на дочерние, или объект. И делать процедуру создания дочерных простой от указателя или методом объекта. Все ведь очень похоже по сути.

← →
Наиль © (2005-08-08 20:39) [7]

Если данных действительно много, то показательным может быть пример СтригГрида. Один объект содержит большой массив. Доступ к нему осуществляется несколькими методами (свойствами) Cells, Rows, Cols. Где Rows, Cols являются объектами но не содержат данных, а используют данные из СтрингГрида.
Такой вариант мне кажется оптимальным - все данные в одном месте, а доступ к ним осуществляется множеством объектов (Cols, Rows). Что касается ТриВью, то его заторможеность обсуждается в соседней ветке. Причина тормознутости проста, отдельный объект для каждого узла дерева.

← →
TStas © (2005-08-08 20:46) [8]

А как раз про tree view думал, но здесь данные должны ссылаться друг на друга непосредственно, поскольку они получаются одно из другого, то есь связные. А вот как отображать их пока конкретных идей нет.
Пример стрингрида хорош, но в моем случае это не массив, а дерево. Почему я об объекте и задумался. НЕ имеет ли смысл создать объект, который бы и содержал данные и занимался обображением их?

← →
Eraser © (2005-08-08 21:03) [9]

TStas © (08.08.05 20:46) [8]

А как раз про tree view думал, но здесь данные должны ссылаться друг на друга непосредственно

Отдели мух от котлет, т.е. данные храни в отдельной структуре-дереве, а для отображения дерева используй tree view, в элиментах которой в поле Data будут содержаться указатели на соотв. записи/объекты в виртуальном дереве.
+ создай процедуру "синхронизации" визуального дерева с виртуальным деревом/списком.

← →
Наиль © (2005-08-08 21:05) [10]

Во всех учебниках написано что дерево это одномерный массив содержащий записи такого вида:
Record
Свой Индекс: Число;
Данные: любого типа;
Индекс родителя: Число;
End;

Я бы сделал так, невизуальный компонент хранящий и обрабатывающий массив. И потомок от ТриВью который занимался бы отображением обработанных данных. Связь через свойство (как DBGrid и DataSet). В таком случае для отображения одного ТриВью достаточно, а отображаемых массивов может быть несколько. Кроме того, без визуализации обработка идёт быстрее. Другой вариант TMemo и TStrings. Первый отображает, второй хранит. Для временного обрыва связи TStrings.BeginUpdate;

← →
ferr © (2005-08-08 23:33) [11]

> Во всех учебниках написано что дерево это одномерный
> массив

Где такое написано?

← →
TStas © (2005-08-08 23:40) [12]

>Наиль
Спасибо за идею.
По сабжу уточню. Что все-таки быстрее будет работать

procedure doSomething(var x:SomeRecord)
или
someObject.soSomething;

← →
Eraser © (2005-08-08 23:45) [13]

TStas © (08.08.05 23:40) [12]

Напрашивается 1 вариант, т.к. [1].
Но подумай о расширяемости программы, с объектами это будет гораздо проще.

← →
Наиль © (2005-08-09 00:07) [14]

>Где такое написано?
Будем считать, что я пошутил.
По большому счёту, память - это одномерный массив.При этом, в ней храняться не только числа, но и прямоугольные фотографии, и объёмные модели, и деревья. В моей практике пришлось работать с кривой находящейся в 11-мерном пространстве, и ничего хранил на диске, как миленькую.
>[12]
Однозначно someObject.soSomething;
Цитата из [1]
Передача указателя на запись вместо самой записи тоже работает быстрее (меньше стековых операций) - особенно, когда этот указатель передается в числе первых 3-х параметров (первые 3 параметра вообще передаются через регистры).

doSomething(var x:SomeRecord) заполняет регистр, но чтобы почуствовать разницу нужно, чтобы в программе кроме вызовов ничего не было, и цикл должен быть бесконечно большой.
a:=b; работает гораздо медленее.
Другими словами, можешь пользовать любым способом, т.к. тормозить будет в других местах.
P.S. Прочитал [13]. Не согласен. Свою версию ответа я проверил отладчиком.

← →
TStas © (2005-08-09 00:26) [15]

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

← →
Eraser © (2005-08-09 00:27) [16]

TStas © (09.08.05 00:26) [15]
Теперь буду думать, как в файл эту структуру сохранять.

TFileStream для этого очень хорошо подойдёт.

>Будем считать, что я пошутил.
> По большому счёту, память - это одномерный массив.При
> этом, в ней храняться не только числа, но и
> прямоугольные фотографии, и объёмные модели, и
> деревья. В моей практике пришлось работать с кривой
> находящейся в 11-мерном пространстве, и ничего хранил
> на диске, как миленькую.

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

По вашему всё храниться линейно? в массивах?

Наиль © (09.08.05 00:07) [14]

В [13] я учитывал далеко не скорость выполнения инструкций procedure doSomething(var x:SomeRecord)
или
someObject.soSomething; как просил автор, а общие затраты памяти и скорость доступа к элименту структуры.
Через массив структур поиск работает однозначно быстрее чем через список объектов.

>Eraser
Да, хорошо. Я им пользовался, когда динамическую структуру хранил, но то был массив записей, пусть и содержащей динамичексие поля, а тут дерево. Надо, наверно, посмотреть, как работает SaveToFile treeView чтобы велосипед не изобретать.

TStas © (09.08.05 01:40) [19]
Надо, наверно, посмотреть, как работает SaveToFile treeView чтобы велосипед не изобретать.

Посмотреть полезно, но только это не поможет. Там названия нодов сохраняются и всё.

Лучше посмотреть как работает LoadFromFile.
В данном случае полезнее.

Какая разница, что выполняется быстрее из [12]? Стас, ты же не брутфорсер, наверное, пишешь? Выгода будет доли секунды. Гораздо больше можно выгадать, если заполнить только первый уровень TreeView и отобразить, а дальнейшее заполнение делать либо при разворачивании узла, либо после заполнения первого уровня, но уже посылая сообщения. Тогда пользователь не заметит никаких тормозов. Но все это стоит делать, если действительно дерево какое-то очень уж большое, глубокое и заметно тормозит. А вообще надо экспериментировать, написать сначала простое, а потом, если не устраивает скорость, думать как оптимизировать. В последствии с приобретением опыта уже сможешь с самого начала оценивать во что примерно тебе это выльется.

>evvcom
Слав, спасибо. Я уже решил, что надо делать. Надо создавать объект, а всю структуру хранить в дереве. В самом объекты хранить лишь ссылку на узел дерева. В этом гарантия, что я не запутаюсь при написании.
>Наиль © (09.08.05 02:31) [21]
>Лучше посмотреть как работает LoadFromFile.
Я это и имел в виду, как у дерева LoadFromFile работает.
Все большое спасибо.

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