User forums > Using Code::Blocks
Code::Blocks slow as molasses
thomas:
I think it is way out of sight. The benefits are not that big, and integrating another editor would take us several months when in fact the Scintilla component is one of the best editing components in existence and works seemlessly and without any problems for most people.
Actually, it works quite well for many people under Linux, too. I don't know what the problem is in your case, but it might really be a setup problem?
When thinking about the integration of a new default editor, remember that you have to make it work cross-platform, you have to interface with wxWidget's drawing and event system in both directions (how do you do that with VIM without rewriting it from scratch...?), have to take care of things like folding as well as colour and syntax styling (all of these are configurable in the settings), and have to rewrite a lot of code that uses or depends on editor functionality (several plugins and core components).
Sorry, but a massive change like this without absolute need is madness. It takes a lot of work, it is unlikely to improve anything (the opposite is likely), and it is possibly never going to work at all.
If the Scintilla control in the main editor were to be replaced, it should at least be something which is based on wxWidgets, so the event handling and the base interfaces would be compatible.
DJMaze:
Scintilla has somesort of bad memory management and this is not C::B related.
I've tested Scite and Notepad2 which both use Scintilla and it gets realy messy on files > 1MB.
For example i opened a 3MB file in Notepad2 and Scintilla popped up a warning box "Are you shure to open this large file"
After clicking yes it took 20 seconds to open the file.
Running a (regex)search took 40 seconds.
In other editors like WinSyntax or UltraEdit i had no issues at all (UltraEdit even 1GB files).
I a haven't looked in the Scintilla source but it seems they only use stack memory which is limited to 1MB per process on windows, or the heap and moving/allocating to much data.
takeshimiya:
--- Quote from: DJMaze on March 21, 2006, 05:48:54 pm ---I've tested Scite and Notepad2 which both use Scintilla and it gets realy messy on files > 1MB.
For example i opened a 3MB file in Notepad2 and Scintilla popped up a warning box "Are you shure to open this large file"
After clicking yes it took 20 seconds to open the file.
--- End quote ---
Sorry I can't confirm that, opening a 50MB file takes less than 3 seconds here in those programs.
What it is a bug in Scintilla is the slowness, that only occurs on GTK on linux and on certain configurations.
thomas:
No offense, but this is plain bullshit. I just edited a 37.5 MB file with 494,000 lines in Code::Blocks to verify this claim. The same block of lines copied and pasted many times, then saved to disk.
On my machine, opening such a ridiculously big file takes about 8-9 seconds, and there is a lag of about half a second while editing. Cutting 50 lines from the middle of the document and pasting in another place (arbitrary position) takes no longer than half a second, either.
Deleting the first 1,000 lines from this document takes about a second. Deleting the next 10,000 lines (after the first 1,000) takes about 12 seconds. Saving that document takes about 3 seconds.
Editing a 2.2 MB file (which is still outright ridiculous) has no noticeable delay at all (cutting and pasting a block the size of about 50% of the text takes under a second).
Similar figures for SciTE, except that SciTE has no noticeable lag at the beginning of arbitrarily large documents (to be honest, I only verified "arbitrarily large" with a 80 MB document). Instead, editing gets delayed only at the end of the document. However, for any reasonable document size (under 5 MB), there is no noticeable delay at all.
How can you call this "bad management"? Honestly, I could not possibly write an editor that performs any better than this (or which even gets near that). Can you?
If you seriously consider editing source files whose sizes are on the order of several megabytes, you have a problem. It is not your editor, though...
EDIT: I forgot to mention that the above numbers include the overhead for the code completion parser, which consumes massive CPU and memory, too. And yet it still works acceptable at file sizes that are really unrealistic (whose source files are >2 MB?).
DJMaze:
Hmmm then it's probably something bad in my computer then when you guys don't have that lag.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version