Speed of VDK_Cursor::ExecuteSql_WithNoUnion()

[Eric Forget]

Hi Ruslan,

Currently, I'm doing a lot of profiling with Shark. Most of the problems are
on my side. However, I found a place where Valentina could be better
optimized.

Here is the stack snippet from Shark:

1     10.3%    VDK_Cursor::ExecuteSql_WithNoUnion(char const*)
2     10.0%        VDK_Cursor::Find_VDK_Objects()
3     10.0%            VDK_BaseObject::GetField(char const*) const
4     9.9%                FBL_String::CompareNoCase(char const*, char
const*, unsigned long)
5     5.5%                    CaseConversionEngine
6     2.1%                    FBL_String::FBL_String[unified](char const*,
unsigned long)    
7     2.0%                    FBL_String::~FBL_String [unified]()
7     0.1%                    strcmp

As you can see the CompareNoCase is taking about 99% of the GetField()
function, while the real compare (strcmp) is taking only 10%. So here is the
source of CompareNoCase():


short FBL_String::CompareNoCase( const char* s1, const char* s2, ulong
inHowMuch )
{
    FBL_String    leftStr( s1, inHowMuch );
    FBL_String    rightStr( s2, inHowMuch );

#ifdef FBL_MAC
    ::UppercaseText( leftStr, (short) leftStr.mLen, smSystemScript );
    ::UppercaseText( rightStr, (short) rightStr.mLen, smSystemScript );
#else
    strupr( leftStr );
    strupr( rightStr );
#endif

    return (short) strcmp( leftStr, rightStr );
}


Problem 1. The constructor and destructor of the 2 FBL_String are taking
near 50% of the execution time of the SQL query. You should try a way to
remove them.

Problem 2. I do not have the source of GetField(), but I believe that one of
the 2 strings is always the same. So, it is made upper case a lot of time.
Doing it just 1 time will reduce execution by another near 50%.

By doing those, you will save around 75% of the time.

Cheers,

Éric


___________________________________________________________________

 Eric Forget                       Cafederic
 ForgetE at cafederic.com             <http://www.cafederic.com/>