Is ParamStr(i) efficient?

[AlexTP]

I saw the code of ParamStr(i) with i>0 and saw it was getting Argc/Argv values, but cannot find details where argv is made. So i ask. Does FPC parse Win32 command line to separate argv's each time I call ParamStr? Or does it parse it once, and saves ParamStr values to argv's?

[Thaddy]

It is exactly just as (in)efficient as in C or C++ or any other language. There is not much to optimize...

[marcov]

I saw the code of ParamStr(i) with i>0 and saw it was getting Argc/Argv values, but cannot find details where argv is made.

rtl/win/syswin.inc line 220 and on.

So i ask. Does FPC parse Win32 command line to separate argv's each time I call ParamStr? Or does it parse it once, and saves ParamStr values to argv's?

Once.  It is part of an unified interface of the system unit to the commandline handling. Mostly everything operates on argv, argc or on fake ones (like Windows, where they are pascal symbols containing the split commandline).

It is exactly just as (in)efficient as in C or C++ or any other language. There is not much to optimize...

On Windows argv and argc Pascal symbols are totally unrelated to whatever C or C++ might or might not do.

[Thaddy]

On Windows argv and argc Pascal symbols are totally unrelated to whatever C or C++ might or might not do.

No. They are - almost - exactly the same. By heritage. You are not often wrong but here you are.
(e.g. in Borland Pascal, Turbo Basic  and Borland C even exactly the same code)

[marcov]

On Windows argv and argc Pascal symbols are totally unrelated to whatever C or C++ might or might not do.

No. They are - almost - exactly the same. By heritage. You are not often wrong but here you are.
(e.g. in Borland Pascal, Turbo Basic  and Borland C even exactly the same code)

Afaik this comes from the parsing from go32v2 extender's argv and argc in ye old days, manually fixed for Windows when it came. Not from Borland*

But the point is that a Windows C compiler will use a different argv and argc, since they are not externals.

They also will be different on Linux (since FPC uses the startup versions, while C programs will use the libc versions, which are hopefully 1:1 tho)

[AlexTP]

syswin.inc

Code: Pascal  [Select][+][-]

1.     procedure allocarg(idx,len:longint);
2.       var
3.         oldargvlen : longint;
4.       begin
5.         if idx>=argvlen then
6.          begin
7.            oldargvlen:=argvlen;
8.            argvlen:=(idx+8) and (not 7);
9.            sysreallocmem(argv,argvlen*sizeof(pointer));
10.            fillchar(argv[oldargvlen],(argvlen-oldargvlen)*sizeof(pointer),0);
11.          end;
12.         { use realloc to reuse already existing memory }
13.         { always allocate, even if length is zero, since }
14.         { the arg. is still present!                     }
15.         sysreallocmem(argv[idx],len+1);
16.       end;
17.  

IMO here we can allocate by 10 elements (for ex), not by 1 element, when idx>=argvlen. this will make 10 times less reallocs.

[marcov]

IMO here we can allocate by 10 elements (for ex), not by 1 element, when idx>=argvlen. this will make 10 times less reallocs.

Code executed once on startup. Is it really worth the extra bytes in every app?

[skalogryz]

It is exactly just as (in)efficient as in C or C++ or any other language. There is not much to optimize...

for comparison, Delphi implementation does parameter lookup on every call to ParamStr()