Hi,

I'm trying to optimize my CSV parser class, and facing with a bit unexpected results. I tried to change in-place set declaration (if ch in [a, b, c] then ...) to reusable set constants (if ch in ABCSet then ...), and noticed a slight slowdown. To check it, I created a simple test application:

const
  cs: set of char = ['a', 'b', 'c', 'd', 'e'];
var
  i: Integer;
  c: Char;
  b: Boolean;
begin
  c := 'a';
  for i := 0 to MaxInt do
  begin
    // A. In-place set declaration
    b := c in ['a', 'b', 'c', 'd', 'e'];
    // B. Set constant
    // b := c in cs;
  end;
end.

I was surprised when B turned out to be almost 3 times slower than A (~11 vs ~29 sec. on my hardware). This ratio remains nearly the same regardless of compiler optimization level.

I'm using FPC 2.4.2 [2010/12/27] for i386 on Linux.

1) Is it expected behavior, or should I create
a bug report about it?
2) What way (A or B) are you using in your programs (or would suggest to use in long term)?

Thanks in advance.

In our previous episode, Vladimir Zhirov said:

I was surprised when B turned out to be almost 3 times slower than A (~11 vs ~29 sec. on my hardware). This ratio remains nearly the same regardless of compiler optimization level.

This is normal. Typed constants are considered variables, and not optimized.

There is a third variant, constant sets

  C)
    const someset = ['A','B','C'); // true constant set

A or C

It's probably because "cs" is a typed constant, meaning it'll become a global variable. If you used

cs = ['a', 'b', 'c', 'd', 'e'];

Then you would probably see the same performance as in a

It's true that the semantics are the same, and it would probably make sense to do some optimizations on typed constants that aren't ever written to(the FPC rtl "abuses" the typed constant variable property in the heap manager code, for example)

2) What way (A or B) are you using in your programs (or would suggest to use in long term)?

I would write it in the way that is clearest to the programmer, and not use typed constants :)

Jeppe Johansen wrote

It's true that the semantics are the same, and it would probably make sense to do some optimizations on typed constants that aren't ever written to(the FPC rtl "abuses" the typed constant variable property in the heap manager code, for example)

I wouldnˈt consider this an abuse as type constants were intended to be "static local variables" when they were introduce.

E.g.

procedure IncCount;
const
   count: Integer = 0;
begin
   Inc(count);
end;

The value of "count" will increase throughout the run, but it won't be visible to other functions/procedures outside this routine (this goes back to the time when Pascal had no units to introduce private variables).

Regards,
Sven