First, when the compiler translates to machine code, Inc is faster than adding...
Ok, I thought this might have been optimized by the compiler but apparently it's not.
But you might have mentioned it was more optimized. Not that it "must be".
(although I'm not sure if with optimization the code might be different)
the FAnotherList.Assign(SL) is intended to take the grouped list out of scope.
Look again closely at your code. The Assign(SL) is INSIDE the for loop. You indented the end wrong. So if you worried about optimization you might want to place that FAnotherList.Assign() OUTSIDE the for loop. (That's why I thought that was a copy-paste error)
I found that there must be a simple correction in stringl.inc file...
simply add (count=0) or to the line having Not Find(S,Result) then
No, that's not a MUST !! It might be a small optimization, though.
But if you look in Find() you'll see, that if count=0, it falls through the L<=R line and Result is false. So (count=0) is the same as Not Find(). So you don't have to check them both.
You still didn't mention if you tried to check the result of Find().
I think you might not be understanding the Find() function correctly.
Note the wiki:
If the string is not found, the function will return False and Index will contain the position where the string will be inserted if it is added to the list.
So, if the string is NOT found, the Index will NOT be -1 (!!!), but it will be the position it would be inserted (hence the 8261232). The function-result will be false in that case. So don't just assume when the result = -1 that the string is not found. You NEED to check the result of Find().
So you need to do something like this:
if SL.Find(vElement['name'], I3) then
begin
// I3 is the found string-index
{some other code that modifies vElement with aritmethic operations...}
end
else
begin
// you could use I3 to insert at position but Add() will do this too (again, so less optimized)
SL.AddObject(vElement['name'], vElement) // create the first
end;