-
-
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.
И еще мне ничего не НАДО, надо тебе, почувствуй разницу.
|