User forums > Using Code::Blocks
Time used to open a file
mandrav:
--- Quote from: MortenMacFly on April 23, 2011, 06:08:34 pm ---
--- Quote from: jens on April 22, 2011, 12:08:30 am ---It's not (yet) tested on windows.
--- End quote ---
Did Yiannis try on Windows?!
--- End quote ---
Nope.
MortenMacFly:
OK, unfortunately this does not work for me on Windows. What happens is that the option to use #defines is ALWAYS set to true whenever I open a file. When I go to editor settings, enable and again disable the option the colouring is correct again. However, opening the next file the setting is again ignored. :-(
thomas:
(slightly off-topic)
A similarly surprising thing is that while Code::Blocks takes a minimum of 5-6 seconds to start up in Ubuntu 11.04 (or any other version I've used it under, for that matter), though under Windows it launches in under a second. Now, yesterday, much to my surprise, I found out that it also launches "almost instantly" (less than a second) under Fedora-14 KDE.
Not like that's likely to be something we can improve, but it's stunning nevertheless how the same software behaves so differently on identical hardware with kind-of-identical operating systems (Linux vs. Linux).
Jenna:
--- Quote from: MortenMacFly on May 04, 2011, 09:26:55 pm ---OK, unfortunately this does not work for me on Windows. What happens is that the option to use #defines is ALWAYS set to true whenever I open a file. When I go to editor settings, enable and again disable the option the colouring is correct again. However, opening the next file the setting is again ignored. :-(
--- End quote ---
Folding is also broken, but I'm working on another patch, that seems to speed loading of very large files much more, but respects folding.
And it doesn't need the cbAuiNotebook-hack hack to speed up loading of many files on linux, it just (really) hides the notebooks while loading.
The current implementation in editormanager {Hide|Show}Notebook does nothing.
I will attach the patch during the day.
Jenna:
Here comes the new patch (attached) and some mesurements I have made:
Opening all files, if project is loaded
1. = default (actual trunk)
2. = HideNotebook (notebook hidden while loading the project)
3. = HideNotebook and move Colourise ( 2. + call to Colourise() moved, so it's called if the editor is empty)
4. = HideNotebook and move Colourise with blocked updates of title and statusbar ( 3. and calls to update title and statusbar for every editor blocked while loading a project)
5. = HideNotebook and move Colourise and ProgressDialog (4. and ProgressDialog while loading the files)
C::B core
1. 467626 ms = 7 m 47.626 s = 100.0 % => gain 0.0 % ( 1.0 x faster than trunk )
2. 348728 ms = 5 m 48.728 s = 74.6 % => gain 25.4 % ( 1.3 x faster than trunk )
3. 345099 ms = 5 m 45.099 s = 73.8 % => gain 26.2 % ( 1.4 x faster than trunk )
4. 342316 ms = 5 m 42.316 s = 73.2 % => gain 26.8 % ( 1.4 x faster than trunk )
5. 423451 ms = 7 m 3.451 s = 90.6 % => gain 9.4 % ( 1.1 x faster than trunk )
test project with five very large (3.5 MB) files
1. 22955 ms = 22.955 s = 100.0 % => gain 0.0 % ( 1.0 x faster than trunk )
2. 18516 ms = 18.516 s = 80.7 % => gain 19.3 % ( 1.2 x faster than trunk )
3. 3624 ms = 3.624 s = 15.8 % => gain 84.2 % ( 6.3 x faster than trunk )
4. 3600 ms = 3.600 s = 15.7 % => gain 84.3 % ( 6.4 x faster than trunk )
5. 3741 ms = 3.741 s = 16.3 % => gain 83.7 % ( 6.1 x faster than trunk )
~200 files web-project (html, php, css, js)
1. 38754 ms = 38.754 s = 100.0 % => gain 0.0 % ( 1.0 x faster than trunk )
2. 24345 ms = 24.345 s = 62.8 % => gain 37.2 % ( 1.6 x faster than trunk )
3. 23446 ms = 23.446 s = 60.5 % => gain 39.5 & ( 1.7 x faster than trunk )
4. 22557 ms = 22.557 s = 58.2 % => gain 41.8 % ( 1.7 x faster than trunk )
5. 24840 ms = 24.840 s = 64.1 % => gain 35.9 % ( 1.6 x faster than trunk )
Changes to enable 4. and 5. are commented out in the patch.
The progress dialog in 5. only exists if all files are opened.
5. eats up nearly all speed-gain on large projects, but on the other hand it shows the user, that something happens and what's more it adds the ability to cancel the loading into the editor (project loading is not affected by cancelling). It can easily be implemented for loading last opened files, too.
A good compromise is 3. loading can not be cancelled, but title and statusbar are updated for each file, so the user sees, that C::B is still working.
The speedup for loading very large files (5 cpp-files with ~ 3.5 MB) is really good and should be visible on windows also.
I will test it tomorrow or this weekend (on win7 64bit).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version