[fpc-devel] for-in-index loop

[Sven Barth]

On 27.01.2013 19:09, Michael Van Canneyt wrote:
>
>
> On Sun, 27 Jan 2013, Sven Barth wrote:
>
>> On 27.01.2013 16:27, luiz americo pereira camara wrote:
>>> 2013/1/26 Sven Barth <pascaldragon at googlemail.com>:
>>>> On 26.01.2013 12:52, Alexander Klenin wrote:
>>>>>
>>>>> On Sat, Jan 26, 2013 at 10:50 PM, Sven Barth
>>>>> <pascaldragon at googlemail.com> wrote:
>>>>>>>
>>>>>>> Generics was implemented without my knowledge. I only found out when
>>>>>>> suddenly
>>>>>>> the classes unit had been changed to use them. After a horrible
>>>>>>> discussion, this was reversed, because of the drop in speed you
>>>>>>> got when
>>>>>>> using generics.
>>>>>>
>>>>>>
>>>>>> Ah! So that is where those ifdefs in classes come from :) I always
>>>>>> wondered...
>>>>>>
>>>>> Is the drop still present/essential? Perhaps optimizer is now good
>>>>> enough to drop those ifdefs?
>>>>
>>>>
>>>> Someone would need to test this. It could be that the generic
>>>> variant is
>>>> less optimal, because the generic list is built upon a list that
>>>> handles
>>>> pointers...
>>>>
>>>
>>> I did some test with generics last year:
>>> http://lazarusroad.blogspot.com.br/2012/06/cost-of-using-generics.html
>>>
>>> I would not use in classes unit
>>
>> That's mostly about the "duplication" problem, which is known (maybe
>> I'll try to improve the situation some time). What would have been
>> more interesting is the performance of the generated code compared
>> with e.g. a TStringList or a TObjectList.
>
> When I tested it, there was a 10% slowdown. It is the difference between
> a direct pointer assignment vs. calling Move() for each assignment.
>

I just checked the code of TFPGList. It does not use Move if you look at 
it correctly:

TFPGList.Add calls TFPSList.Add with the address of the argument.
TFPSList.Add in turn (basically) calls TFPSList.CopyItem which (in so 
far you are right) is implemented using Move. But this method is virtual 
and overridden in TFPGList where it's an assignment between dereferenced 
pointers to the generic type T.

But maybe it would still be faster if TFPGList would not be derived from 
TFPSList, but completely implement the list handling itself with an 
"array of T" and using just assignments. It could be that all those 
virtual method calls are the "problem" here...

> Regardless, I don't see the need of replacing proven code with generics
> just as a showcase for generics. If it ain't broken, don't fix it.

As I just wrote to luiz: I'm not suggesting to change anything in 
Classes regarding usage of generics. I'm just curious regarding their 
performance behavior.

Regards,
Sven