User forums > Using Code::Blocks
Code::Blocks very slow to open long files
dmoore:
i would assume that this would be a temporary linux-only change. someone should file a bug with the wx guys (perhaps with a minimal sample to demonstrate the problem)
dmoore:
--- Quote from: Biplab on May 08, 2008, 06:54:44 pm ---I've found out a better solution for this problem. :D
--- Code: ---+ iconv_t cd = iconv_open("ISO-8859-1", "UTF-8");
--- End code ---
--- End quote ---
correct me if I'm wrong, biplab, but all you need to do to make this operational is to add a function that maps the wxFontEncoding typedef to the strings that iconv can handle?
Biplab:
--- Quote from: MortenMacFly on May 08, 2008, 07:34:00 pm ---Although this is a very nice idea anyways, but you are aware, that this massively "complicates" the compilation on Windows, right?
--- End quote ---
Not really. GTK+ team uses win_iconv on Windows which is purely written in Win32 API and is very easy to compile on Windows. Visit it's homepage (You need to translate it) :
--- Quote ---http://yukihiro.nakadaira.googlepages.com/
--- End quote ---
Or just download the compiled package from the following page.
--- Quote ---http://www.gtk.org/download-windows.html
--- End quote ---
--- Quote from: MortenMacFly on May 08, 2008, 07:34:00 pm ---I'm not sure on how many libs iconv itself depends but I would guess it's not a "stand-alone".
--- End quote ---
It has no external chain of dependency. So rest be assured that it'll not increase the overhead.
--- Quote from: MortenMacFly on May 08, 2008, 07:34:00 pm ---So the question is either we find another solution or probably (as this seems to be a Linux only thing) we make this implementation on Linux only... Any thoughts?
--- End quote ---
IMO, we can make the changes for Linux only where libiconv.so is available.
But my real concern is not the compilation of iconv on Windows or so. My major concern is to see that the iconv and wxWidgets work together without creating nuisance. That's why I thought of wrapping iconv as a separate plugin so that it doesn't affect the core code.
I've already noticed problems with some encodings with the new patch. wx fails to accept the passed wchar_t pointer and the conversion looses several paragraphs of characters. I guess it's about more number of NULL chars at the end confuses wx.
--- Quote from: dmoore on May 09, 2008, 01:27:13 am ---correct me if I'm wrong, biplab, but all you need to do to make this operational is to add a function that maps the wxFontEncoding typedef to the strings that iconv can handle?
--- End quote ---
Yes it is. IIRC, iconv supports more encodings than wx handles. That's one reason I wanted to implement it as a separate plugin. Also read the problem I wrote in previous para.
Biplab:
Well folks, I need to say that the earlier patch was incorrect and it doesn't solve the problem. Sorry for the noise. :oops:
Actually the delay is because C::B tries to convert the file from UTF-8. Then this conversion fails as the file is in different encoding (This process is consuming time). Then the fallack encoding converts it properly.
The file is converted in just 8 milliseconds if correct encoding is used.
I'm looking for a solution to this problem.
dmoore:
sorry to resurrect -- has this been solved? I still seem to be seeing longer than necessary file open times on my linux boxes...
Navigation
[0] Message Index
[*] Previous page
Go to full version