User forums > Using Code::Blocks

Code::Blocks very slow to open long files

<< < (3/6) > >>

dmoore:
i just ran through a few debug sessions. seems like the bottleneck is in the encoder. specifically,

line 93 EncodingDetector.cpp  (see *** CHOKES HERE **** line below)

--- Code: ---bool EncodingDetector::ConvertToWxStr(const wxByte* buffer, size_t size)
{
    if (!buffer || size == 0)
        return false;

    if (m_BOMSizeInBytes > 0)
    {
        for (int i = 0; i < m_BOMSizeInBytes; ++i)
            *buffer++;
    }

    size_t outlen = 0;
    wxCSConv conv(m_Encoding);

/* NOTE (Biplab#5#): FileManager returns a buffer with 4 extra NULL chars appended.
    But the buffer size is returned sans the NULL chars */
    wxWCharBuffer wideBuff = conv.cMB2WC((char*)buffer, size + 4 - m_BOMSizeInBytes, &outlen);  ****CHOKES HERE*****
    m_ConvStr = wxString(wideBuff);


--- End code ---

strangely, this code gets called twice every file open (and is slow each time)

UNRELATED OBSERVATION: when i remove breakpoints in an active debug session, the breakpoints remain (this is a pretty longstanding issue with debugger plugin in cb)

thomas:
One possible cause might be this:

--- Quote from: wx/strconv.h ---// inLen is the length of the buffer including trailing NUL if any: if the
// last 4 bytes of the buffer are all NULs, these functions are more
// efficient as they avoid copying the string, but otherwise a copy is made
// internally which could be quite bad for (very) long strings.
--- End quote ---
Of course the documentation doesn't have any mention of that, you have to dig through the headers to find it.

However, FileManager already adds 4 gratious null bytes to every loaded file to prevent some other crap wxWidgets string function from crashing in UTF-16/UTF-32 mode, so actually this situation should not be possible.
Maybe the string conversion function is counting them from the wrong location though, who knows? Even though copying 500 kB of data shouldn't take 15 seconds... but who knows, maybe they make 20,000 copies? :)

afb:
Opens up directly on Mac OS X, for both wxMac and wxGTK versions of Code::Blocks.
Though the GTK+ version uses ANSI, so it probably didn't need to convert very much.

So looks like it is something specific to Unicode or Linux, or maybe even just Ubuntu ?

thomas:
If I've followed the never ending chain of macros, functions, and macros renaming functions correctly, it's
mbsrtowcs which finally gets called in Unicode build (ANSI build copies the data to a new buffer using strncpy).
So, is there a way to trace mbsrtowcs to confirm or reject the "it's an Ubuntu thing" hypothesis? Something similar to strace maybe...?

mandrav:
Yes, I can confirm it's the call to mbsrtowcs that's causing the slow down. Unfortunately, I 'm not sure we can do anything about that... :(

On the bright side, I found out why the encoding detection was called twice and fixed it. This means that the slow-down time is now cut in half. That's something, at least.

Navigation

[0] Message Index

[#] Next page

[*] Previous page