Эх так приятно, когда...

← →
Дмитрий С © (2011-07-15 14:39) [0]

... когда оптимизация процедуры действует так, что она вместо 40 секунд выполняется 0.4, жертвуя всего лишь 400кб оперативки :)
А вам когда приятно?

← →
SQLEXPRESS (2011-07-15 14:40) [1]

а кто стесняется если сказать, что говорить?

← →
TUser © (2011-07-15 14:47) [2]

чаще - когда вместо года получается минута, жертвуя всего лишь 10% точности ))

← →
MonoLife © (2011-07-15 15:33) [3]

> А вам когда приятно?

провокационный вопрос:)

← →
И. Павел © (2011-07-15 15:54) [4]

> А вам когда приятно?

В пятницу в 15:59 весьма приятно, и, думаю, не мне одному :)

← →
SQLEXPRESS (2011-07-15 16:08) [5]

У Вас, сударь, часы на 5 минут вперед от православного :)

← →
Jeer © (2011-07-15 16:11) [6]

> А вам когда приятно?

В созерцании красоты.
Это может быть девушка рядом или результат аскетичного кодинга :)

← →
_Юрий (2011-07-15 19:14) [7]

Если такой выигрыш в скорости, правильнее назвать это не оптимизацией, а исправлением ошибки.

← →
Rouse_ © (2011-07-15 19:30) [8]

Прирост с 40 до 0,4 весьма значителен - поздравляю.
Мы тут тоже с Ega23 неделю бились над загрузкой большого блока данных и разворачивание его в памяти (оптимизация загрузки древовидного блока данных из ~ 16 миллионов не сортированных узлов, каждый из которых за собой тянет блоки несортированных данных в подузлах размером от 4 байт до 39Кб с сортировкой при загрузке + второе дерево рефов на узлы основного). В итоге оптимизировали скорость загрузки с ~35 минут до полутора секунд (минус затраты на зачитку данных с файлов - от секунды, до восьми... тут все от кэша системы зависит)

← →
Дмитрий С © (2011-07-15 19:59) [9]

> Rouse_ © (15.07.11 19:30) [8]

Я сначала не прочитал то что в последних скобках, подумал нихрена себе чтение порядка 100МБ в сек:)) Круто, блин, это всегда приятно:)
А кстати как дерево организовано? Id, ParentId ? Или NestedSets ?

← →
Rouse_ © (2011-07-15 20:09) [10]

Id, ParentId.
работа без реаллоков памяти тупо считываем все и ручками расставляем указатели на правильный элемент в Raw буфере

← →
b z (2011-07-15 20:29) [11]

> [8]
А что за задача? ну если не секрет. :)

← →
Дмитрий С © (2011-07-15 20:36) [12]

> Rouse_ © (15.07.11 20:09) [10]

Такая идея сразу в голову приходит, а если еще таблицу смещений в этом Raw буфере закешировать на диске, да и еще и в правильном порядке?

← →
Jeer © (2011-07-15 20:49) [13]

> Rouse_ © (15.07.11 20:09) [10]
>
> Id, ParentId.
> работа без реаллоков памяти тупо считываем все

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

← →
Rouse_ © (2011-07-15 21:15) [14]

> b z (15.07.11 20:29) [11]
> А что за задача? ну если не секрет. :)

ИСС банальный. Текстовых данных ~13 гектаров + каждый месяц прирост по 500 метров. Грузить индекс нужно при старте.

> Дмитрий С © (15.07.11 20:36) [12]
а если еще таблицу смещений
> в этом Raw буфере закешировать на диск

это тоже часть алгоритма :)

> Jeer © (15.07.11 20:49) [13]

Самый геморой тут был в том что Дельфя пыталась помогать, т.е. нужно было обойти лишние _Move/_CopyRecord и т.д. и естественно отойти от идеологии TMyObject.LoadFromStream - ибо зачем копировать данные в свой обьект, если данные уже есть в памяти... Ну а дальше все само-собой.

← →
Дмитрий С © (2011-07-15 21:28) [15]

> Jeer © (15.07.11 20:49) [13]

А зачем нужен Treeview в миллионами элементов? Пользователь всеравно все не сможет посмотреть.

← →
Rouse_ © (2011-07-15 22:30) [16]

> Дмитрий С © (15.07.11 21:28) [15]
> А зачем нужен Treeview в миллионами элементов?

Это-ж дерево а не список, представь что в руте всего 5 элементов и в чайлдах тоже пять, и так далее рекурсивно... Пользователь видит только необходимые ему 5 штук и все... Ну хотя опять-же, все зависит от задачи...

← →
DVM © (2011-07-15 22:51) [17]

> Rouse_ © (15.07.11 22:30) [16]

> Это-ж дерево а не список,

тем более, зачем грузить то, чего не видно

← →
Jeer © (2011-07-15 22:57) [18]

> DVM © (15.07.11 22:51) [17]
>
>
> > Rouse_ © (15.07.11 22:30) [16]
>
>
> > Это-ж дерево а не список,
>
> тем более, зачем грузить то, чего не видно
>

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

← →
DVM © (2011-07-15 22:59) [19]

> Jeer © (15.07.11 22:57) [18]

> Потом решил, что ошибся и перечекнул ниже или выше.

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

← →
Jeer © (2011-07-15 23:02) [20]

нереально.
После такого решения мне была бы секир башка

← →
картман © (2011-07-15 23:03) [21]

> А вот прикинь - пользователь чекнул верхний айтем для составления
> запроса со всеми вложенными чайлдами и ?

и загрузил пять штук

> Потом решил, что ошибся и перечекнул ниже или выше.

и еще пять

> Если дерево не подгружено в память, пипец наступает очень
> быстро.

при скорости нажатий 2М/сек

← →
DVM © (2011-07-15 23:05) [22]

> Jeer © (15.07.11 23:02) [20]

> нереально.

Что не реально? Асинхронный запрос сделать нереально с отменой закачки данных (а еще лучше с фоновой подгрузкой) при клике по другому узлу? Всем можно сделать. Нагрузка на сервер ляжет правда.

← →
Jeer © (2011-07-15 23:05) [23]

Понятно, что задачи у всех разные.

Для OLAP - надо предоставлять пользователю быстро визуально формировать многомерный запрос с различными вариантами отметки сущностей в древовидной и естественной для человека иерархии предметной области.

В том и дело - все на клиенте, т.к. задача обеспечить единообразие работы с различными СУБД.
Сил и средств на реализацию и поддержку серверных решений такой задачи ( MS SQL, FireBird, Oracle, ...etc) никто не дает.

> картман © (15.07.11 23:03) [21]
>
>
> > А вот прикинь - пользователь чекнул верхний айтем для
> составления
> > запроса со всеми вложенными чайлдами и ?
>
> и загрузил пять штук

Какие пять штук ?
Там может быть прорва штук, если грузить по "пять" - жизни не хватит.
Наконец о может чекнуть один из верхних уровеней и сделать запрос.
Ждать пока выстроится дерево ?
Потом выполнится запрос, потом разборка "шахматки" ?
Уволят :)

А разделить данные и их представление в голову не приходило? Если у тебя в памяти дерево из миллиона классов, это совсем не значит, что тебе нужно TreeView насиловать.

Ребят, а чего вы накинулись то?
ТЗ выданное Jeer-у, никто-ж из вас не читал, а посмотреть - так все герои :) (шутка)
А в ТЗ нюансы и обговорены... сущности они из нюансов и строяться...

> нужно TreeView насиловать.

Этим занимаются полторы тыщи пользователей, как минимум.
Ежедневно, регулярно и бездумно - им бы нажимать, понимаешь.
Поэтому и было выполнено такое построение системы - распределенное.
Серверу - все чисто реляционное, а построение двумерных срезов гиперкуба - на клиентский машинах.
В итоге система одновременно работает с разными СУБД ( на сегодня MSSQL, Oracle и Firebird )
На серверах нет ничего, кроме чистых таблиц, даже View нет, не говоря уже о..

> Rouse_ © (16.07.11 00:07) [27]
>
> Ребят, а чего вы накинулись то?

Дык треплемся, для того и форум.
Так-то понятно, что перед работодателем отвечать Jeer"у, а не коллективному разуму потрепаловки :)

> Так-то понятно, что перед работодателем отвечать Jeer"у,
> а не коллективному разуму потрепаловки :)

Та не.. все нормально.
Система по такой схеме работает свыше 5 лет - полет нормальный.
Ее более дебильный аналог - ГАС "Управление" от пермской фирмы "Прогноз".
prognoz.ru
Не, ну сам-то "Прогноз" вроде востребован, хотя по мне - так вполне достаточно мат.пакетов: "Статистика", SPSS и иже с ними.

> [30] Jeer © (16.07.11 00:54)

одного беглово взгляда на сайт достаточно, чтобы голове возникло слово "откат" ;-) это безотносительтно к самой программе, еще качеству или конкретной организации ;-)

> одного беглово взгляда на сайт достаточно

Даже не глядел. Мне достаточно слов Сергея и Александра. Ни разу их не ловил на использовании телесных наказаний для бедного существа по имени "чушь". :)

← →
_Юрий (2011-07-17 12:19) [33]

Если даже не глядеть, шансы поймать стремятся к нулю.
В принципе, это удобно.

Эх так приятно, когда... Найти похожие ветки