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. -- Best regards, José
arraytest.pas
Description: Binary data
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel