Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC: Expensive calls on opening new files
dmoore:
yes, please clean up as you see fit (would it be possible to switch off the event responder altogether the save the function calls?)
unfortunately, I can't say I used any special tool to find the problem other than C::B itself (lots of find in files and find implementation of). I know that on Linux you can use callgrind (part of valgrind) to produce call statistics, but I'm not familiar enough with that tool or the C::B code to use it effectively (you have to have an idea of what code should be called thousands of times and what shouldn't).
The main reason I was able find the problem came from playing around with big files and from recent stuff I learned while playing with scintilla (adding the php lexer and my wild goose chase with wxIdleEvents). Scintilla is very event driven, so it was just a case of figuring out which events were creating lags or conflicts... there may still be more issues that callgrind might be able to unearth.
It also helps that you guys have writen very clear modular code! :) (despite wxwidgets macro heavy implementation)
back to the Function Parsing code - delaying till all project files are open is good, but then it appears that the parsing occurs on the main thread, which blocks the UI until it's done, which kind of defeats the purpose of waiting...
and next problem: after the editor loses then regains focus, the function parser appears to reparse the whole file if you click on the class/function browser drop down. should only happen if file is modified right? (unless the data is released when the file loses focus?)
Biplab:
--- Quote from: dmoore on June 22, 2007, 03:35:50 am ---unfortunately, I can't say I used any special tool to find the problem other than C::B itself (lots of find in files and find implementation of). I know that on Linux you can use callgrind (part of valgrind) to produce call statistics, but I'm not familiar enough with that tool or the C::B code to use it effectively (you have to have an idea of what code should be called thousands of times and what shouldn't).
--- End quote ---
I'll post a Callgrind log tonight (Now it's morning for me), too, if I can set it up properly. :)
--- Quote from: dmoore on June 22, 2007, 03:35:50 am ---back to the Function Parsing code - delaying till all project files are open is good, but then it appears that the parsing occurs on the main thread, which blocks the UI until it's done, which kind of defeats the purpose of waiting...
and next problem: after the editor loses then regains focus, the function parser appears to reparse the whole file if you click on the class/function browser drop down. should only happen if file is modified right? (unless the data is released when the file loses focus?)
--- End quote ---
These problems needs attention. :)
rickg22:
--- Quote from: dmoore on June 22, 2007, 03:35:50 am ---
back to the Function Parsing code - delaying till all project files are open is good, but then it appears that the parsing occurs on the main thread, which blocks the UI until it's done, which kind of defeats the purpose of waiting...
--- End quote ---
Actually the parsing isn't that slow. It's just one file. What makes it so slow is the event handling related to it. But if you wish, we can [ EDIT: at a *LATER* stage*, hope that clears it up, Don Corleone ;-) ] fix that, too. Volunteers? (I have thread-phobia :P )
--- Quote from: dmoore on June 22, 2007, 03:35:50 am ---and next problem: after the editor loses then regains focus, the function parser appears to reparse the whole file if you click on the class/function browser drop down. should only happen if file is modified right? (unless the data is released when the file loses focus?)
--- End quote ---
Yes, I noticed that. Curiously, this was the same redundant behavior that I *just* fixed in TODO list. So I'm changing it so it will parse *ALL* the open files at once, and just switch from the results whenever you change the active file.
mandrav:
I must admit I 'm kind of scared with some of the things I read here...
I 'm not saying you don't have a point: you may very well be right.
BUT...
I 'm afraid of such optimizations at such a late stage by people who are not very familiar with the particular code. And don't take this as an insult please. You all remember the time when CC was responsible for every bad thing in C::B. We don't want to go back there, do we?
All I 'm saying is that if you want to "play" around with the code and try to optimize things you 're very welcome to do so. But in a separate branch of the code. I don't want the risk of ruining what we already have, even if it's not performing optimally.
So, if it's a new branch you need created, just ask me and I will create one for you.
Thanks again for your efforts :).
rickg22:
Yiannis: Don't worry about the thread problems! I'm not touching THAT thing (eew :-P ). It was just a suggestion, I have to admit sometimes I get misinterpreted (ah, remember the old times? :) ). I said "we" as "the team" because I don't want to meddle with multithreading. I still have open sores about that ;-)
However, about prefetching the function lists, it's a simple change, I already tried in the todo list, and it worked wonders (that was BEFORE i had discovered the huge memory leak).
Rest assured, I'm not letting the multithreaded creature go rampant again :lol:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version