UnicodeStrings

45 views
Skip to first unread message

Leonel Togniolli

unread,
Sep 22, 2010, 9:51:44 AM9/22/10
to llvm-...@googlegroups.com
Notei o checkin com suporte a D2009+ e os problemas de performance.
Não baixei o código pra testar (nem tenho tempo em um futuro próximo),
mas minha experiência é a seguinte:

Usar AnsiStrings em todo lugar vai derrubar a performance, sem dúvida.
Cada função chamada pra processar uma string vai causar duas ou mais
conversões de ansi->unicode e vice versa. Adicionar a unit AnsiStrings
(se me lembro bem) no uses vai diminuir um pouco isso, pois ela possui
as versões antigas das funções de manipulação de string. Conversões
ainda vão acontecer ao utilizar classes e funções fora dessa unit.
Setar {$STRINGCHECKS OFF} no D2009 e D2010 vai ajudar um pouco também
(isso não existe mais no XE, e é ignorado).

A alternativa que recomendaria é encarar o unicode e utilizar strings
mesmo. Primeiro para facilitar o tratamento de arquivos em
unicode/outras codepages, tanto comentários/strings contendo
caracteres especiais quando indentificadores em unicode (é possível
ter uma variável chamada 'ação" desde o D2005, se me lembro bem). Não
que sejam uma boa idéia, mas acho importante para paridade de
linguagem.

E segundo, para ajudar a definir como o llvm-pascal vai lidar com
unicode, que pessoalmente acho um recurso extremamente importante.

--
Leonel

Wanderlan

unread,
Sep 22, 2010, 11:05:10 AM9/22/10
to llvm-pascal
Olá Leonel,

> Usar AnsiStrings em todo lugar vai derrubar a performance, sem dúvida.
> Cada função chamada pra processar uma string vai causar duas ou mais
> conversões de ansi->unicode e vice versa.

Realmente as conversões é que estão reduzindo a performance no D2009+.
Mas o quebra-galho que fiz foi para incentivar quem tem D2009+ a
testar
o LLVM-Pascal.

> Adicionar a unit AnsiStrings
> (se me lembro bem) no uses vai diminuir um pouco isso, pois ela possui
> as versões antigas das funções de manipulação de string.

Boa dica vou experimentar.

> Conversões ainda vão acontecer ao utilizar classes e funções fora dessa unit.
> Setar {$STRINGCHECKS OFF} no D2009 e D2010 vai ajudar um pouco também

Testei isso e não notei melhoria.

> (isso não existe mais no XE, e é ignorado).
>
> A alternativa que recomendaria é encarar o unicode e utilizar strings
> mesmo. Primeiro para facilitar o tratamento de arquivos em
> unicode/outras codepages, tanto comentários/strings contendo
> caracteres especiais quando indentificadores em unicode
> (é possível
> ter uma variável chamada 'ação" desde o D2005, se me lembro bem). Não
> que sejam uma boa idéia, mas acho importante para paridade de
> linguagem.

Em Java também existe isso e ninguém que conheço usa ou pretende usar
essa loucura em qualquer linguagem de programação.
Assim estou decidindo por não suportar isso, pelo menos até a versão
1.0.

O grande problema é que o LLVM-Pascal irá usar a RTL do FreePascal ou
a free-CLX.
Está fora do meu escopo fazer uma RTL do zero. Mas vou ter que fazer
pequenas adaptações na RTL do FPC, pois não irei suportar ASM...
Eu preciso de uma RTL free e uma vez que não posso usar a RTL que vem
no Delphi, por questões de copyright, a opção natural é a RTL do FPC.
Além disso a RTL precisa ser multiplataforma... E isso no Delphi é
outra novela.
Como o FPC adota outra solução para Unicode esse é o caminho natural
para o LLVM-Pascal.
No fim das contas o objetivo final é compilar o Lazarus, obviamente um
remix com adaptações.

Obrigado,
Wanderlan
Reply all
Reply to author
Forward
0 new messages