Brian Stevens a écrit :
> 
> On Apr 14, 2008, at 2:32 PM, Alain Pastor wrote:
>> Walter Lenk a écrit :
>>>
>>> LOCAL:DIM HX$, c%
>>> LOCAL FN Make_Hex_Line$(A$,bk%)
>>>   LET A$ = LEFT$(A$,52)
>>>   LET HX$ = ""
>>>   DEFSTR BYTE
>>> * FOR c% = 1 TO A$[0]
>>> *   LET HX$ += HEX$(A$[c])
>>>     IF ((c% MOD bk%) == 0) THEN LET HX$ += " "
>>>   NEXT c%
>>> END FN = HX$
>>
>> Walter,
>>
>> I believe you should gain a little speed by replacing the following line:
>>
>> LET A$ = LEFT$(A$,52)
>>
>> With:
>>
>> IF A$[0] > 52 THEN A$[0] = 52
>>
>> I think also that A$[0] forces the CPU to read the value in memory, 
>> and I believe this value is read each iteration of the loop, so 
>> perhaps it would be a tiny bit faster to have the value in a register.
>>
>> Furthermore according to your code it is not necessary to truncate the 
>> A$ variable.
>>
>> dim upLimit
>> upLimit = A$[0]
>> IF upLimit > 52 THEN upLimit = 52
>>
>> FOR c% = 1 TO upLimit
>>
>> Someone will correct me if I am wrong, but it's worth testing.
> 
> Definite improvements from Alain. Only one comment on Alain's code:
> 
> IF A$[0] > 52 THEN A$[0] = 52
> 
> is helpful and makes this line:
> 
> IF upLimit > 52 THEN upLimit = 52     unnecessary since upLimit has 
> already been limited to 52 or less in the first statement.
> 

OK, I meant that Walter should use either the first method or the second 
(with upLimit).

> local fn Make_Hex_Line_Test$( a as Str255, bk as short )
> '~'1dim as Str255    hx
> dim as short     c, upperLimit
> if a[o] > 52 then a[0] = 52// set length byte to 52 or less

Poking a value like done on the line above is not mandatory considering 
how Walter uses the A$ variable further in his code. I think the three 
lines of code introducing upLimit as I did above should suffice.

> defstr byte
> upperLimit = a[0]
> for c = 1 to upperLimit
> hx += hex$(a[c])if (( c mod bk ) == 0 ) then hx += " "
> next
> end fn = hx
> 
> It might be slightly faster to pass a pointer to a string to the 
> function instead of passing a string and returning a string. This might 
> make a little difference for a function called this many times. I 
> haven't checked FBtoC code to see what is faster but pascal strings get 
> copied to/from a global stack and that might be part of the speed issue. 
> If I have time I'll check and see what is generated.
> 
I thought of passing the pointer to the string, but I didn't mention 
that because I found out to my surprise that I couldn't gain any speed 
(sometimes the resulting code ran even slower as per the Profiler) with 
that method. At least, I'm speaking about FB and as far as my tests went 
in those old days, of course I don't know how it would fare with FBtoC. 
Perhaps, someone could explain this oddity in FB.

Alain