Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Optimizing Makefilegenerator

(1/5) > >>

rickg22:
After seeing how long large projects take to calculate the compilation commands, i realized that the string replacing is EXTREMELY SUBOPTIMAL.

    compilerCmd.Replace(_T("$compiler"), compilerStr);
    compilerCmd.Replace(_T("$linker"), m_CompilerSet->GetPrograms().LD);
    compilerCmd.Replace(_T("$lib_linker"), m_CompilerSet->GetPrograms().LIB);
    compilerCmd.Replace(_T("$rescomp"), m_CompilerSet->GetPrograms().WINDRES);

etc.

My proposal is to use wxStringTokenizer to search for the macros (using '$' as token), and do the replacing manually using the Matches() function. This will allow us to speed up the generation time by around 15x.

Objections? Comments?

mandrav:
It's not replace that slows down this process. It's the calls to wxFileName::Normalize. For each file and for each build target, filenames are recalculated. We have lowered this overhead a lot by caching the calculated filenames and recalculating them when needed.
It will be optimized even more with the optimizations Thomas will do to project loading.

And all these are only noticeable in *large* projects like C::B itself...

rickg22:
Awww... and *just* when I came up with the idea of a cacheable search-and-replace class... :(  :lol:

Anyway, how did you find out the normalizing was the most time-consuming part?
Do you happen to have a profiler report? (I'd love to see it)
Can anybody help us with the profiling?

rickg22:
Hey wait a minute!

I just noticed something VERY SUSPICIOUS.


--- Code: ---lines 224 and following:
    if (target &&
        target->GetParentProject()->GetModeForPCH() == pchObjectDir)
    {
        wxArrayString includedDirs; // avoid adding duplicate dirs...
        wxString sep = wxFILE_SEP_PATH;
        // find all PCH in project
        int count = target->GetParentProject()->GetFilesCount();
        for (int i = 0; i < count; ++i)
        {

--- End code ---

Does this loop get executed EVERYTIME CreateSingleFileCompileCmd is invoked? :shock: That adds QUADRATIC complexity! :shock:

Oh wait, nevermind, that option is not executed in my setup.... darn, I really need profiler info...

mandrav:
MakefileGenerator is used as a quick hack to generate the build command line. It will need to be rewritten anyway as it doesn't support many of the newest features.
I will implement another optimized command-line generator for builds.
It won't take long...

Navigation

[0] Message Index

[#] Next page