ScInterpreter::ScPropper() Optimization?

I found some interesting code inside the function 
ScInterpreter::ScPropper() [in interpr1.cxx]. namely, there
is a while 
loop and an unnecessary subtraction is nested inside this
while loop:

see   pStr[nPos - 1]


    while( nPos < nLen )
    {
        aTmpStr.SetChar( 0, pStr[nPos-1] );        //    
<----------HERE
        if ( !ScGlobal::pCharClass->isLetter( aTmpStr, 0
) )
            pStr[nPos] = pUpr[nPos];
        else
            pStr[nPos] = pLwr[nPos];
        nPos++;
    }

This could be easily rewritten to:

    xub_StrLen nPos = 0;                   //  <---------
MODIFIED
    const xub_StrLen nLen = aStr.Len() - 1; // 
<--------- MODIFIED
   // NEED TO TEST (aStr.Len() == 0) ???
    while( nPos < nLen )
    {
        aTmpStr.SetChar( 0, pStr[nPos] );        // 
<--------- MODIFIED
        nPos++;         //  <-------------------- MOVED
HERE
        if ( !ScGlobal::pCharClass->isLetter( aTmpStr, 0
) )
            pStr[nPos] = pUpr[nPos];
        else
            pStr[nPos] = pLwr[nPos];
        // nPos++;         //   <------------------ MOVED
 BEFORE  IF
    }
    aStr.ReleaseBufferAccess( nLen + 1);  // <-----
MODIFIED
    PushString( aStr );

Is this optimization feasible?

Sincerely,

Leonard

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesc.openoffice.org
For additional commands, e-mail: dev-helpsc.openoffice.org

Leonard Mada wrote:
> I found some interesting code inside the function 
> ScInterpreter::ScPropper() [in interpr1.cxx]. namely,
there is a while 
> loop and an unnecessary subtraction is nested inside
this while loop:
> 
> see   pStr[nPos - 1]
> 
> 
>    while( nPos < nLen )
>    {
>        aTmpStr.SetChar( 0, pStr[nPos-1] );        //   
 <----------HERE
>        if ( !ScGlobal::pCharClass->isLetter(
aTmpStr, 0 ) )
>            pStr[nPos] = pUpr[nPos];
>        else
>            pStr[nPos] = pLwr[nPos];
>        nPos++;
>    }
> 
> This could be easily rewritten to:
> 
>    xub_StrLen nPos = 0;                   // 
<--------- MODIFIED
>    const xub_StrLen nLen = aStr.Len() - 1; // 
<--------- MODIFIED
>   // NEED TO TEST (aStr.Len() == 0) ???
>    while( nPos < nLen )
>    {
>        aTmpStr.SetChar( 0, pStr[nPos] );        // 
<--------- MODIFIED
>        nPos++;         //  <--------------------
MOVED HERE
>        if ( !ScGlobal::pCharClass->isLetter(
aTmpStr, 0 ) )
>            pStr[nPos] = pUpr[nPos];
>        else
>            pStr[nPos] = pLwr[nPos];
>        // nPos++;         //   <------------------
MOVED  BEFORE  IF
>    }
>    aStr.ReleaseBufferAccess( nLen + 1);  // <-----
MODIFIED
>    PushString( aStr );
> 
> Is this optimization feasible?

That wouldn't give any noticeable performance gain (probably
not even 
measurable), so let's keep the old code. Having a variable
nLen contain 
the string length, as the name suggests, is also easier to
read and 
understand.

Niklas

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesc.openoffice.org
For additional commands, e-mail: dev-helpsc.openoffice.org