Тоды ОЙ

Я внес некоторые исправления. Не принципиальные абсолютно.
1) Изменил имя PArray - неправильно, что оно совпадает с именем типа из share (хотя все и работает)
2) Изменил положение методов в файле (тупой Move) - чтобы лежали группками с предварительным комментарием: группка для строк, для целых, для действительных.

Посему, файл теперь другой немного: http://forum.hiasm.com/getfile/38278

--- Добавлено в 2018-01-01 23:14:03

3042, вот чего я думаю про твой код.
Увеличение длины массива на 1 много-много раз приводит дельфячий реаллокатор памяти немножечко в состояние ступора...
Мне так показалось. Как, впрочем, и для оригинального кода.

KOL-вский TList поступает немножечко по другому. Count - это один разговор, а Capacity - это другой разговор, и именно он определяет количество реаллоцированной памяти. Если Count становится больше Capacity, то реаллоцируется сразу на 25% больше. А не на 1 поинтер.
Здорово экономится на операциях динамического выделения памяти.
Свечку я конечно же не держал, но кажется, что все именно так и происходит.
Где-то я читал (не помню уже где), что Дельфи со строками работает похожим образом. Поэтому многократное добавление одного символа в зад строки не вызывает особых проблем.


И еще. Все эти MoveMemory жрут таки время... И заметно это не на тех файлах, которые Вы, 3042, давали для теста.
Самый плохой случай - обратно отсортированный список (для прямо отсортированного - это просто добавление в зад).
Я брал Ваш файл Книга1.txt и сортировал его в обратном порядке (у меня это запросто делает текстовый редактор)

Редактировалось 2 раз(а), последний 2018-01-01 23:14:03

ОК (про PArray я тоже был слегка удивлён : )
Положимся на Ваш опыт, Galkov

nesco, мы Вас ждём! Обновите, пожалуйста, на SVN.

Редактировалось 1 раз(а), последний 2018-01-02 00:04:31

Обновил

Совсем забыл, nesco, ещё нужно обновить ini (там увеличил номер версии и указал, что на нижней точке массив отсортирован).

Тоже где-то читал такое. Но потом выяснилось, что 500Кб строка переводится в Base64 за 40 сек. на не самом слабом компьютере. Так что ну его нафиг такой способ, если количество операций больше нескольких десятков.

Редактировалось 1 раз(а), последний 2018-01-02 14:00:09

Ну конечно ну его нафиг, если без него можно обойтись.
Ибо сказано, что лучшее средство от перхоти - гильотина

В данном конкретном случае, почти избежать работы с хипом можно просто одной реаллокацией в начале цикла.
Что-то типа такого: SetLength(RealArray, ArrIn._Count);

Однако беда в том, что это пока только идея, доведение которой требует некоторой работы.
И при этом, сейчас это не самое больное (в плане быстродействия) место.
Большее время забирают MoveMemory.
Это видно из разницы во времени обработки прямо- и обратно-отсортированных массивов.
В обоих случаях количество реаллокаций одинаково, а MoveMemory отрабатывают совсем уж разные объемы памяти (~0 и по максимуму).

Редактировалось 1 раз(а), последний 2018-01-02 16:04:17

Ну вы блин даёте!
Без праздников работаете? + всем к пенсии!

... и бинареый поиск шустрый, если конечно можно применить...
Вот про хешь таблицы (массивы) в HiAsm ни слова, а инструмент достойный!
Вот делал на заре моего творчнмтва в HiAsm, когда толком и компонент не мог сделать.
http://forum.hiasm.com/getfile/38280
Можно до ума довести.
А может и не надо.
В словаре Зализника (царство ему небесное) ищет слово, максимум за два шага, а у Мюлера (не группенфюрера СС) за шаг.
Шаг - хешь адрес, - не мне вам объяснять.

А ещё, много чего нет, нормальных списков, деревьев, а не в KOL транскрипции - по сути обман.
(А Крафоген должен быть сожжён.)
Заготовки для нейронныж сетей - тоже подойдут. А сколько вариантов...
Чего копья ломать, когда проект закрыт?
И в HiAsm можно, если с умом.

Я ахереваю дорогая редакция http://forum.hiasm.com/topic/66478
Типа - Простота, хуже воровства.

Редактировалось 7 раз(а), последний 2018-01-02 22:45:46