UDF: Собственно, симметричный алгоритм шифрования сделал такой:

Надо бы как-то ускорить и улучшить его.

Это сообщение отредактировал(а) Alexeis - 30.3.2007, 20:31

А что тут упрщать то  Два цикла всего...

Ну не знаю. Думаю, что sum, len и res - лишние.
Может, asm?

tishaishii, пару советов:
не придумывай шифрование. используй готовое, пока не отягощен хотя бы минимальными знаниями в данной области. нагромаждение xor'ов не повышает степень "зашифрованности". "на глазок" можно оценить качество(это даже не качество, а скорее степень скрытости от любопытных(домохозяек)) "шифровки" путем передачи функции длинной последовательности одинаковых символов - должна получиться "каша", а не повторения последовательностей.

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

Ооочень пафосный ответ, о, Великий.
Ты же не знаешь всю предисторию, о, Мудрец.

tishaishii, всё правильно сказано. Если под словом "улучшить" имелось ввиду сделать более стойким, то тебе придётся отказаться от xor'a или комбинировать. А ускорять тебе нечего, кроме одного: Вместо типов string используй pchar и днамическое выделение памяти(размер-то тебе известен), а то при использовании типов string в твоём случае больше половины времени тратится на перераспределение для строки. 

Слушай: ты приходишь в магазин покупать видюху и знаешь какую надо, она там есть в наличии и по цене подходит вполне. А продавец, сволочь, всё время тебя мучает своими домыслами и пересудами: "Лучше купите то, это - [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме], я лучше знаю". И думаешь: "куда я попал?". Продавец - сам идиот.

Я не прошу советов и ваших домыслов, я прошу, пожалуйста, помогите ускорить и улучшить алгоритм, который я предложил.

Твой алгоритм нельзя улучшить. Улучшенная версия -- это уже совсем другой принцип и алгоритм.

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

если покупатель начинает доставать продавца вопросами "а как улучшить эту видюху, как сделать ее более быстрой, и чтоб памяти побольше", то продавец, вполне обоснованно, предложит другую видеокарту. так что идиот в данном случае - покупатель.
свободен.

Если продавца стал спрашивать, то считаешь, что он больше знает. А продавец - его роль такая: продавать, а если его это раздражает или ещё какие неудобства ему причиняет - ему можно просто уволиться, чтобы избежать этого. Вспоминаются советсике магазины, где воняет старой колбасой и за прилавками стоят старые толстые продавщицы, которым всё пофиг и на всех.
Наговорили очень много, а такой ерунды сделать не сумели.
Об чём это может говорить.

Это сообщение отредактировал(а) tishaishii - 2.4.2007, 09:26

tishaishii, Этот алогритм изначально страдает проблемой неверной передачи данных.
Строка при выходе из функции автоматически удаляется, если не увеличен ее внутренний счетчик ссылок. Этот счетчик меняется только если String присваивается String-у, а тут такого не происходит, потому по выходу из процедуры память строки считается освобожденной и может использоваться любыми другими процедурами. Вероятнее всего это произойдет при вызове именно функции из этой библиотеки, так как менеджер памяти у библиотеки и у программы разный. Почему строка сразу же не портиться, а потому что менеджер памяти не может освободить для Windows слишком маленький фрагмент памяти, но он может его выделить повторно для другой процедуры, если ей нужен небольшой фрагмент памяти, тогда она приспокойно запишет свои данные поверх имеющихся и возникнет непонятный глюк.
    Result:=PChar(res); - вот так делать нельзя впринципе. Это ошибка, которая всплывет где-нибудь ниже по коду. 

tishaishii
Я, в общем-то, согласен со многим из того, что здесь говорилось, но если уж тебе так хочется оптимизировать именно твой алгоритм, то навскидку могу предложить так:

Можно, конечно, еще поизвращаться во второй функции, но боюсь ощутимого прироста производительности или экономии не получится...