Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Скорость сравнения строк в Ansi и Unicode формате.

Страницы: 1 2 3 >
Riply © (2007-10-31 03:51:00)
Здравствуйте !
Допустим, у нас есть две строки:
wBuf1, wBuf2: WideString;
и они же, "переведенные в Ansi": aBuf1, aBuf2: string;
Верно ли следующее утверждение:
регистро-зависимое сравнение aBuf1 и aBuf2 будет выполняться быстрее,
чем регистро-зависимое сравнение wBuf1 и wBuf2 ?

guav (2007-11-02 22:00:00) [1]
Сравни
> REPE CMPS D
> JNE @@2
> MOV ECX,EDX
> REPE CMPSB

и

> REPE CMPS W

посимвольно :)

Функция тоже использует вычитание символов, и в отличии от RtlCompareUnicodeString всегда использует такое вычитание (это работает т.к. #0 меньше любого символа)

Riply (2007-11-02 21:51:00) [2]
> [57] guav © (02.11.07 21:43)
> Ищет нуль в конце одной из строк для определения длины, затем сравнивает по два байта.

Именно это меня и интересовало. Спасибо.
Т.е. использует "посимвольное" сравнение как и RtlCompareUnicodeString
и не пытается сравнивать по четыре байта ?

guav (2007-11-02 21:43:00) [3]
Ищет нуль в конце одной из строк для определения длины, затем сравнивает по два байта.
использует то что в конце обязателен нуль, в отличии от RtlCompareUnicodeString, которая не рассчитывает на это и готова прнять нули в середине.

Riply (2007-11-02 21:34:00) [4]
Вот натолкнулась на функцию в WideStrUtils:

function WStrComp(const Str1, Str2: PWideChar): Integer; assembler; asm PUSH EDI PUSH ESI MOV EDI,EDX MOV ESI,EAX MOV ECX,0FFFFFFFFH XOR EAX,EAX REPNE SCASW NOT ECX NOT ECX MOV EDI,EDX XOR EDX,EDX REPE CMPSW MOV AX,[ESI-2] MOV DX,[EDI-2] SUB EAX,EDX POP ESI POP EDI end;

Она внутри использует что-то типа CompareMem или
"по идеологии" похожа на RtlCompareUnicodeString в [35] Riply © ?

Riply (2007-11-02 10:59:00) [5]
> [54] Anatoly Podgoretsky © (02.11.07 10:35)
> Но если есть желание то могу выслать на твой почтовый ящик.

Желание есть. :) Буду очень признательна.

P.S.
Надеюсь моя анкета цела. Вроде надавно перерегистрироавлась.

Anatoly Podgoretsky (2007-11-02 10:35:00) [6]
> Riply (02.11.2007 10:28:53) [53]

Ну сейчас она перешла в разряд платных, возможно где то в файловых архивах еще валяются старые бесплатные версии.
Но если есть желание то могу выслать на твой почтовый ящик. Библиотека достойная. Базовая версия 2.2.5., размер 260 кб в zip
А найти легко, через поисковую систему - TntUnicodeControls

Riply (2007-11-02 10:28:00) [7]
> [52] Anatoly Podgoretsky © (02.11.07 09:50)
> TNT Contros и не должного уровня и не покрывает все потребностей, хорошо хоть базовые покрывает.
> Я во всех проектах использую эту библиотеку в обязательном порядке.

"Чем дальше в лес - тем больше дров".
Впервые слышу об этой библиотеке. Где ее можно посмотреть и потрогать ?

Anatoly Podgoretsky (2007-11-02 09:50:00) [8]
> Riply (02.11.2007 09:30:51) [51]

Дельфи это не благоприятствуют, TNT Contros и не должного уровня и не покрывает все потребностей, хорошо хоть базовые покрывает. Я во всех проектах использую эту библиотеку в обязательном порядке. Есть и реальная нужда во многоязычие и нет желания бороться с локализациями конкретных машин, да и не возможно это по большому счету.

Riply (2007-11-02 09:30:00) [9]
> [50] Anatoly Podgoretsky © (01.11.07 23:15)
> Попутно можно выяснить, что Ansi функции могут не работать в общем случае,
> никогда нет гарантии в возможности преобразования Юникод в Ansi

Тоже очень полезное "выяснение" :)
P.S.
Похоже пора работать только в UNICODE - проблем меньше, "взаимопонимания" с системой больше :)

Anatoly Podgoretsky (2007-11-01 23:15:00) [10]

> зато выяснили,
> что многие Ansi функции работают через UNICODE.

Попутно можно выяснить, что Ansi функции могут не работать в общем случае, никогда нет гарантии в возможности преобразования Юникод в Ansi

Riply (2007-11-01 20:59:00) [11]
> [46] clickmaker © (01.11.07 12:22)
> мужской? :)

Над этим вопросом еще не задумывалась.
А в какой нынче модно уходить ? :)

> [48] Anatoly Podgoretsky © (01.11.07 12:27)

> Не нужно, для Юникод кодов менее $10000 ucs-2 совпадает с utf-16

Ну и слава богу. Работы меньше :)

Из этой ветки я вынесла следующее:
Мне надо было имеющийся лист(массив) UNICODE_STRING`ов
обработать (сортировка, поиск дубликатв) и преобразовать в ANSI.
Вопрос был в следующем: что сначала преобразовать в Ansi или обрабатывать.
Если я правильно поняла, то обработка его в исходном виде лучше.
Ускорения при использовании Ansi мы не обнаружили, зато выяснили,
что многие Ansi функции работают через UNICODE.

За что всем большое спасибо :)

Anatoly Podgoretsky (2007-11-01 12:27:00) [12]

> > Зато можно попробовать использовать RtlCompareMemory :
> )
>
> Но не нужно :), наверное.

Не нужно, для Юникод кодов менее $10000 ucs-2 совпадает с utf-16

Anatoly Podgoretsky (2007-11-01 12:24:00) [13]

> Код, чесно говоря, не совсем Microsoft`овский.

Не суть важно, можно говорить по данному коду, этот работает с ucs-2

clickmaker (2007-11-01 12:22:00) [14]

> то ухожу в монастырь

мужской? :)

Riply (2007-11-01 11:21:00) [15]
> [44] Riply © (01.11.07 11:11)
> Зато можно попробовать использовать RtlCompareMemory :)

Но не нужно :), наверное.
Хотя внешне и кажется, что это "оптимизирует", но что-то здесь "не то".
Они же так не поступили.
Скорее всего мы начнем проигрывать на строках, различающихся символами, близкими к началу строки.

Riply (2007-11-01 11:11:00) [16]
> [43] guav © (01.11.07 11:03)

> Сравнение CompareMem а не по символам там нельзя применить,
> т.к. функция должа вернуть не просто равенство или неравенство.

Зато можно попробовать использовать RtlCompareMemory :)

guav (2007-11-01 11:03:00) [17]
Да. RtlCompareUnicodeString работает именно так.
.7C917800: 668B4D08 mov cx,[ebp][00008] .7C917804: 663B4D10 cmp cx,[ebp][00010] .7C917808: 74DE je .07C9177E8

Сравнение CompareMem а не по символам там нельзя применить, т.к. функция должа вернуть не просто равенство или неравенство. Оптимизировать такое сравнение можно: сравнивать DWORDы, при неравенстве перед вычетанием для выдачи ответа менять порядок байт на нужный.

guav (2007-11-01 09:59:00) [18]

> Так я про UCS-2 и говорил, а в Википедия пишут другое, что
> мол UTF-16, а что на самом деле - является тайной

Тайны нет, MSDN тоже утверждает что UTF-16.

Riply (2007-11-01 09:58:00) [19]
> [39] Anatoly Podgoretsky © (01.11.07 09:50)
> Так я про UCS-2 и говорил, а в Википедия пишут другое, что мол UTF-16,
> а что на самом деле - является тайной, но по приведеному коду этого не видно.

Код, чесно говоря, не совсем Microsoft`овский.
Взят отсюда: http://www.reactos.org/generated/doxygen/d8/d16/unicode_8c-source.html
Но я не думаю, что в таком важном вопросе ReactOS`овцы
позволили себе вольный перевод или авторскую правку :)

guav (2007-11-01 09:55:00) [20]
Это именно код Windows ?
Хотя, да, так и сравнивают. Мне удалось создать разные файлы с именами "Ä" (U+00C4), и "A" + "¨" (U+0041 U+0308).

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »