Hello FPC,

Based in the optimizations to CompareByte and FillChar, I get a suspect about record assignment when records are not very big, so write some test code to verify it, and yes, I think code generator should be changed in some way to get advantage in case of "small" records < 96 bytes.

This are the test times:

Rounds: 100000 Array fast (96) : 2110
Rounds: 100000 Array slow (96) : 2265

Rounds: 100000 Array fast (64) : 1391
Rounds: 100000 Array slow (64) : 1969

Rounds: 100000 Array fast (32) : 640
Rounds: 100000 Array slow (32) : 1641

Rounds: 100000 Array fast (16) : 328
Rounds: 100000 Array slow (16) : 1641

The code basically have a record with a series of integer fields and try to copy the record several million times. When the record is 8 bytes long, it generates fast code, but when record size is 16 the code generator jumps to use the "rep movsl" which seems to be ineficient for such small records.

16 and 32 bytes records takes almost the same time to be copied, while the the "by members" copy is between 3 and 5 times faster.

Fast and slow "16" records:

TRFast=record
  r1: record
    a: integer;
    b: integer;
  end;
  r2: record
    c: integer;
    d: integer;
  end;
end;
TRSlow=record
  a: integer;
  b: integer;
  c: integer;
  d: integer;
end;

Loop test code:

for k := 1 to TESTELEMENTS-1 do begin
  ArFast[0].r1:=ArFast[k].r1;
  ArFast[0].r2:=ArFast[k].r2;
end;
for k := 1 to TESTELEMENTS-1 do begin
  ArSlow[0]:=ArSlow[k];
end;

Complete test functions are attached. Thinking in the amount of 32 byte records that can be found in a program this optimization can take a good speed advantage.

Hello FPC,

I forget to say that my machine test is a Intel Q9300 4Core, running WinXP SP3 32 bits.