Code::Blocks very slow to open long files

[Dahman]

I've noticed that code::Blocks is very slow to open files (.txt) with a lot of lines (ex. 50.000).
Often it takes more than 30 seconds.
Is it just me?

Thank for any advice

Dahman

[thomas]

Created a file with >60k lines (6.6 MiB) by concatenating ntbtlog.txt a dozen times, takes under a second to load on my old Athlon64.

So, to answer your question: yes.

[MortenMacFly]

Often it takes more than 30 seconds.

When you say "often" this obviously means "not always". So why don't you provide us with an example so we can reproduce?! ;-)

[Dahman]

Thanks for your replay.

My file is a sort of a log file witch is produced by writing some traces of my project.
When I said "often" I meant the file often exceed 50-60 K of lines and in that case code::Blocks become slow (very slow).
As soon as I go home I will send you an example.

By the way, I am using Ubuntu 7.04 and Code::Blocks 8.02.

Thank you again

[Dahman]

Hello,
Here is an attached example (nothing special, it is just a zipped text file).
To open this file, Code::blocks take exactly 16 seconds.
The same file is opened in 1 second with gEdit.

Thanks for any tip.

Dahman

[attachment deleted by admin]

[thomas]

Roughly 1 second here (maybe a bit less, who can tell), rev 5028 on Windows XP.

[dmoore]

Hello,
Here is an attached example (nothing special, it is just a zipped text file).
To open this file, Code::blocks take exactly 16 seconds.
The same file is opened in 1 second with gEdit.

Thanks for any tip.

Dahman

try:
1. removing the file from any open projects that it might be in
2. switching off code completion plugin

does either of these make a difference?

[MortenMacFly]

Roughly 1 second here (maybe a bit less, who can tell), rev 5028 on Windows XP.

Same here (same revision, too), for sure less than a second. Works very fast - as expected. :-(

[manowar]

I can confirm the issue here. I opened the file on hardy using codeblocks 5020 (from LGP repository) and it took about 12-15 seconds to open it. It is quite slow indeed. My machine is a dual core athlon 3800. I tried to open it with geany and gedit, it takes less than a second. There is definitely something wrong on linux platform. (Disabling the codecompletion does not improve anything)

[dmoore]

I can confirm the issue on Ubuntu 8.04 with all plugins turned off. I remember making some patches many months ago that fixed file opening delays on win32, but those problems were nothing like this. Scite opens the same file instantaneously

[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: [Select]

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);


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:

// 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.

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.