[nem-en] Location without bit-hanting :)

[Igor Tkachev]

Hello Michal,

BTW, Michal, before you leave, can you add new category to Mantis to
track integration issues? And access for us to be able to change the
issue status?



Sunday, September 10, 2006, 4:10:53 AM, you wrote:

> If it doesn't degrade performance I'm all for it.

> Kamil probably won't answer as he's on vacations (for about 3 weeks
> from now). I'm leaving for a week on Thursday BTW.

> On 9/10/06, vc <vc at rsdn.ru> wrote:
>>
>>    Michal, Kamil... What do you think about it?
>>
>>    >       The location bit hack (col, line, ... represented as a single
>>    > field)
>>    > makes a lot of problems. For example, it does not support negative
>>    > values
>>    > needed for relocation algorithm used to compensate editing changes (in
>>    > VS
>>    > 2005 and other IDE).
>>    >
>>    >       I made some changes (see a patch file in the attachment) and
>>    > replaced
>>    > the single field with normal fields.
>>    >
>>    >       This solution solves the following problems.
>>    >
>>    >       1. It eliminates restrictions on file count and location line and
>>    > col
>>    >          values.
>>    >       2. Removes Location dependence on ManagerClass. In this case file
>>    >          index is globally unique, so is thread safer.
>>    >       3. Simplifies the source code.
>>    >
>>    >       This solution does not affect the compiler performance at all.
>>    >
>>    >       Pentium M 1.7 1 Gb RAM (notebook)
>>    >
>>    >       Current boot binaries took:
>>    >       56 sec. and 150 Mb peak of memory size.
>>    >
>>    >       In Debug mode it took:
>>    >       55 sec. and 171 Mb peak of memory size.
>>    >
>>    >       In Release mode it took:
>>    >       54 sec. and 150 Mb peak of memory size.
>>    >
>>    >       Dual Core Genuine 2GHz 2 GB RAM (notebook)
>>    >
>>    >       Current boot binaries took:
>>    >       44 sec. and 154 Mb peak of memory size.
>>    >
>>    >       In Release mode it took:
>>    >       44 sec. and 133 Mb peak of memory size.
>>    >
>>    >       Really, this solution apparently does not affect the performance
>>    > and
>>    > solves many problems.
>>    >
>>
>>
>> _______________________________________________
>> https://nemerle.org/mailman/listinfo/devel-en
>>

-- 
Best regards,
 Igor                            mailto:it at rsdn.ru