-
-
program Project1;
uses
KOL;
procedure FillTVWithFL(TV: PControl; FL: PStrList);
function ItemIndex(Parent: Cardinal; ItemName: string): Cardinal;
var Item: Cardinal;
begin
Result := 0;
Item := TV.TVItemChild[Parent];
while Item <> 0 do
begin
if AnsiCompareStrNoCase(TV.TVItemText[Item], ItemName) = 0 then
begin
Result := Item;
Break;
end;
Item := TV.TVItemNext[Item];
end;
end;
var
i: Integer;
s, s1: string;
Parent, Item: Cardinal;
begin
for i := 0 to FL.Count - 1 do
begin
s := FL.Items[i];
s1 := Parse(s, '\');
Parent := TVI_ROOT;
while s1 <> '' do
begin
Item := ItemIndex(Parent, s1);
if Item = 0 then
Parent := TV.TVInsert(Parent, TVI_SORT, s1)
else
Parent := Item;
s1 := Parse(s, '\');
end;
end;
end;
var
Form, TV: PControl;
SL: PStrList;
begin
Form := NewForm(nil, 'TV');
TV := NewTreeView(Form, [], nil, nil).SetAlign(caLeft);
SL := NewStrList;
SL.Add('D:\Program Files\Borland\Delphi6\Source\Vcl\Printers.dcu');
SL.Add('D:\Program Files\Borland\Delphi6\Source\Vcl\WinHelp.dcu');
SL.Add('C:\WINNTS\system\BORLNDMM.DLL');
FillTVWithFL(TV, SL);
SL.Free;
Run(Form);
end.
-
пасиба
-
хм а ВКЛьный вариант в 6 раз быстрее !!! 8,6 секунд против 50 при списке из 10000 файлов так что зря Дмитрий К исключил CachedStrs из алгоритма :(
-
не знаю точтоли я перевел ВКЛьный вариант с CachedStrs, тем не менее работает ,но скорость всего лиш 36 против 50 походу в даном случае CachedStrs особо не при делах,а просто ВКЛ имеет по полной КОЛ в плане скорости procedure FillTreeViewWithFiles(TreeView1: PControl; Strs: PStrListEX);
var
CachedStrs: PStrListEX;
procedure AddItem(Lev: Integer; ParentNode: Cardinal; S: string);
function FindNodeWithText(AParent: Cardinal; const S: string): Cardinal;
var
K: Integer;
fStr: string;
tmpNode: Cardinal;
begin
Result := 0;
fStr := S + Int2Str(AParent);
K := CachedStrs.IndexOf(fStr);
if K > -1 then
Result := CachedStrs.Objects[K]
else
begin
if AParent <> 0 then
tmpNode := TreeView1.TVItemChild[AParent]
else
tmpNode := TreeView1.TVRoot;
while tmpNode <> 0 do
begin
if TreeView1.TVItemText[tmpNode] = S then
begin
Result := tmpNode;
CachedStrs.AddObject(fStr, tmpNode);
break;
end;
tmpNode := TreeView1.TVItemNext[tmpNode];
end;
end
end;
var
prefix: string;
ID: Integer;
aNode: Cardinal;
begin
if S = '' then
Exit;
ID := Pos('\', S);
prefix := '';
if ID > 0 then
prefix := Copy(S, 1, ID - 1)
else
begin
prefix := S;
S := '';
end;
aNode := FindNodeWithText(ParentNode, prefix);
if aNode = 0 then
begin
aNode := TreeView1.TVInsert(ParentNode,TVI_LAST,prefix);
end;
AddItem(Lev + 1, aNode, Copy(S, ID + 1, Length(S)));
end;
var
K: Integer;
begin
CachedStrs := NewStrListEx;
try
for K := 0 to Strs.Count - 1 do AddItem(0, 0, Strs.Items[K]);
finally
CachedStrs.Free;
end;
end;
-
хм простая конструкция типа procedure TForm1.Button2Click(Sender: TObject);
var i: Integer;
debug:cardinal;
begin
debug:=gettickcount;
for i := 0 to 10000 do
begin
TV.Items.AddChild(nil,'Item' + InttoStr( i ));
end;
form1.Caption:=inttostr(gettickcount-debug);
end; показывает КОЛ=13672 мс ВКЛ=11265 мс что просто работа с деревом "почти" одинакова тогда где тормоз который дает 6 кратный разнос ???
-
кстати !!! а какова? просто добавление итемов у ВКЛ медленей чем ВКЛьная версия FillTreeViewWithFiles ???
-
Ставь FastMM4 и будут пузомерки работать примерно одинаково.
-
> Ставь FastMM4
совет ниочем причом тут смена менеджера память ? если тормозит конкретно коловский вариант алгоритма,а оба они используют стандартный менеджер
-
"Вам шашечки или ехать?"
-
> "Вам шашечки или ехать?"
переведи
-
Я думаю с "переводом" любой гугл справится. А что касается советов - они бывают двух видов "спасибо, помогло" или "нет не помогло, давайте еще подумаем"...
-
спасибо, не помогло :)
-
Достаточно посмотреть код из VCL и подумать над ним. Да, в полтора раза быстрее. Но во сколько раз больше? И зачем? treeview с более чем 1000 элементов будет всяко работать настолько медленно, что имеет смысл обойтись без него. Например, изобразить дерево в виртуальном listview. Приведенный пример на 10000 элементов на одном уровне не показателен. Выполните цикл еще раз и потом закройте окно. Ожидание 20 или 30 секунд закрытия - какая разница? Это в любом случае превышает секунду, что есть разумное время ожидания. Не стои свеч, в общем. А KOL предназначен для уменьшения размера приложения.
-
> Vladimir Kladov
НЕНЕ, вы не поняли малость, разница в 6 (шесть) раз !это написано выше функции максимально (насколько можно) идентичны для кол и вкл (я про FillTreeViewWithFiles)
> Приведенный пример на 10000 элементов на одном уровне не > показателен.
в том то и дело что почемуто ВКЛу быстрей выполнить FillTreeViewWithFiles чем просто забить 10000 элементов на один уровень
> Ожидание 20 или 30 секунд закрытия - какая разница?
вот имено что никакой ни при каких условиях: КОЛ-50 секунд,ВКЛ-8.6 секунд, а это АХРИНЕТЬ какая разница
кроме того с учетом того что при простой забивке 10000 элементов на один уровень не большая разница,напрашивается мысль что тормозит не дерево а что то другое... например StrList и\или работа со строками
-
> КОЛ-50 секунд,ВКЛ-8.6 секунд,
а если кол-программу не из дельфи запускать? У меня всего на секунду медленнее выполняется.
-
Сырцы не смотрел, но раз пошла такая пьянка, то есть PFastStrList, PList...на худой конец свой алго написать...
-
Таки заставили глянуть в сырцы - "ахринеть какая разница" потому-что ищете в отсортированном списке строк и в VCL при поиске это учитывается... Таки внимательнее надо портировать.
-
> Таки внимательнее надо портировать
ну про сортировку вы зря, ее влияние было проверено сразу и собствено как отключение ее в ВКЛ так и включение в КОЛ НИКАК не влияют на процесс и собствено алгоритм написан так что ему реальньно пофег на нее
> Таки заставили глянуть в сырцы
вот надо было СНАЧАЛА глянуть а потом советовать
> Ставь FastMM4
> а если кол-программу не из дельфи запускать?
мм щас прям так не скажу но вроде без делфи тажа фигня проверю точней через пару часов
-
FastMM4 стандартное решение позволяющее ускорить работу со строками (результаты в различных случаях отличаются на порядки). Утверждение того что включение/выключение сортировки в VCL никак не влияет на IndexOf - полный бред. В KOL, вроде, преимущества поиска в отсортированном списке строк не используются, точно уже не помню. То что кому-то кажется что алгоритм никак не зависит от сортировки - это не значит что он от нее не зависит LOL.
И еще мне ничего не НАДО, надо тебе, почувствуй разницу.
-
> Утверждение того что включение/выключение сортировки в VCL никак не > влияет на IndexOf - полный бред
а тыбы посмотрел как устроен IndexOf и понялбы что не влияет т.к. перебор идет в ЛЮБОМ случае от начала до конца списка и выход при нахождении и если ты ищеш тот элемент который в сортированом списке лежит в конце,то он найдется позже чем в несортированом(например находится по середине) LOL.
> проверю точней через пару часов
я фигею, реально тормоз при запуске из под делфи причом даже при отсутствии отладочной инфы
-
А может сам посмотришь как в VCL реализовано - файлик Classes.pas - ищем - и всматриваемся до просветления: function TStringList.IndexOf(const S: string): Integer; begin if not Sorted then Result := inherited IndexOf(S) else if not Find(S, Result) then Result := -1; end;
-
незнаю че ты докопался до сортировки но факт, что по вопросу данной темы ее влияние отсутствует т.к. IndexOf в коле реализован также как в вкл и такимже образом используеца в алгоритме а список дается уже сортированым
-
Все-таки вы не в то место в исходниках аосмтрели, QAZ. Основная разница в том, что VCL для ускорения поиска в дереве испольузет виртуальность (LPSTR_TEXTCALLBACK) и фактически строит свой дубль дерева в оперативной памяти. В итоге для доступа к содержимому узлов он смотрит просто на то, что лежит в памяти. Версия KOL минимальна, в ней все делает система. За каждым узлом надо лезть через функции API, что намного дольше. А смысла развивать эту тему я не вижу. В любом случае, хоть на VCL, хоть где, деревом treeview не рекомендовано пользоваться, если число узлов может быть больше 1000. Для VCL я написал FastTreeView на работе, на базе ListView, и мне там до лампочки, хоть сотни тыщ узлов, все работает в пределах допустимой реакции. Но и кода там прилично получается, на то он и VCL.
-
да со скорость все ясно, это изпод делфи тормозит а без него нормально
а по поводу того что не рекомендуется больше 1000 если можно ссылку на микрософт а то все любят вспоминать рекомендации и ограничения относящиеся к 16битным прогам и виндам типа 9х однакош прогресс не стоит на месте :) в мсдн я на такие рекомендации не натыкался , да и дерево мое в 10000 узлов живет и чувствует себя прекрасно,да и с большим числом думаю справица не хуже
-
http://support.microsoft.com/kb/182231Хорошо, если точно известно, что число узлов не превысит 10000. Но и то медленно. В моём случае число узлов заведомо может превышать, а тормозов и без treeview хватало, чтобы ещё и здесь ждать считая секунды после каждого клика.
-
> http://support.microsoft.com/kb/182231
не катит :) там речь идет о Visual Basic 4.0 и о 16разрядных WORDах (типа максимум 65535) а современка вся работает на DWORDах кроме того тормоза в Visual Basic это неудивительно в принципе-ибо тупо скрипт вот спецально завтра проверю на 100 000 итемах :)
-
прикольно итемы больше 65535 в дерево добавляются вроде без проблем а вот скролбар который к нему цепляеца не может скролить больше (позиция у него WORD а макс.значение в DWORD пипец косяк)
скорость добавления падает в 10 раз примерно после 20000 с 1000\сек до 100\сек эт если в один уровень вбивать,а если ветвиться то сразу 100\сек это все на пень4 1.6 ггц с учетом processmessages и выводом в заголовок формы
на скорость навигации ничего не влияет
-
Про VB - это просто пример для воспроизведения. VB в настоящий момент - это полностью 32-разрядный ООП-язык, отличается от C++ практически только синтаксисом и отсутствием асм-вставок. Компилятор слабоват, код не сильно заоптимизирован, но в принципе тех тормозов, что характерны для интерпретируемого Бэйсика древности, давно уже нет.
-
Ну ведь говорили что не рекомендуется)
-
> Ну ведь говорили что не рекомендуется)
ну знаеш что, не рекомендуется... как я написал вся проблемма в скролбаре,а он цепляется автоматом к любому контролу который может скролица буть то листвиев , листбокс или мемо и соответствено любой из них будет при скроле глючить если число строк больше 65535
такчто проблем не в дереве а вобще в принципе... в висте и винде7 проблема не устранена
> VB в настоящий момент - это полностью 32-разрядный ООП-язык
если вы про .NET, то бейсик там уже не язык а просто вариант написания кода также как и сишарп и любой другой который там используется
-
любой из них будет при скроле глючить если число строк больше 65535 опрометчиво, listview - хоть миллиард... Только все-таки лучше его делать виртуальным.
в висте и винде7 проблема не устранена и не будет никогда устранена - для treeview.
> VB в настоящий момент - это полностью 32-разрядный ООП-язык если вы про .NET Нет, я про VB, а не про VB#. Единственный его существенный недостаток - это большая библиотека времени выполнения, не предустановленная в системе, и монстроподобная среда разработки (ms vc++), при том, что она значительно проигрывает delphi по удобству и скорости. А так, разработчиков на западе подавляющее большинство сидят именно на VB.
-
Не согласен.. по скорости среда VB не уступает Delphi. А местами и по удобству рулит, но тем не менее с вб ушел на делфи..
|