Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Does anyone know why Code References Search is sloooooow sometimes?
- Thread starter GriffMG
- Start date
Koen Piller
Programmer
Hi Griff,
No, I dont know why CodeReference is confirmed to be very slow sometimes however have you ever tried GoFish? You may find it at VFPX. You can download the app at: and since it is still daily updated, I could advise you to install also PEM-Editor also at VFPX thus giving you option to make an automatic update to the latest version of both PEM and GoFish. (this automatic updating is byitself already a very dandy piece of coding)
Gofish has a different GUI compared to CodeReference but once you are used to it, you will find: a) GoFish finds everything (more than CR and b) it is always about 5(!) times faster.
Enjoy it.
Regards,
Jockey(2)
No, I dont know why CodeReference is confirmed to be very slow sometimes however have you ever tried GoFish? You may find it at VFPX. You can download the app at: and since it is still daily updated, I could advise you to install also PEM-Editor also at VFPX thus giving you option to make an automatic update to the latest version of both PEM and GoFish. (this automatic updating is byitself already a very dandy piece of coding)
Gofish has a different GUI compared to CodeReference but once you are used to it, you will find: a) GoFish finds everything (more than CR and b) it is always about 5(!) times faster.
Enjoy it.
Regards,
Jockey(2)
- Thread starter
- #3
TamarGranor
Programmer
My experience is that when the Debugger is open, Code References is very slow.
Tamar
Tamar
- Thread starter
- #5
Mike Lewis
Programmer
My experience is that when the Debugger is open, everything is very slow.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Thread starter
- #7
It's wierd, yesterday CR was soooo slooooow on a given project, today - same project, it's brill.
I don't use the debugger, so it can't be that.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I don't use the debugger, so it can't be that.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
Mike Lewis
Programmer
When it's running slowly, are any of the files that you're searching open elsewhere in VFP? For example, a form open in the form designer?
I don't know if that would be the reason for the slowness, but it would be worth checking.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
I don't know if that would be the reason for the slowness, but it would be worth checking.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Thread starter
- #9
Would you mind terribly, colleagues, if I put in my 2 cents? ![[smile]](/data/assets/smilies/smile.gif "[smile] [smile]")
I happen to notice that when the search is performed against the modules in the project that do have "PR" part in the extension (i.e. PRG, MPR) the search goes quite fast, whereas search against those having "X" (i.e. SCX, VCX), which are, essentially, tables with Memo fields, goes much slower.
Methinks the Code References function goes record by record in those tables, hence the slowliness of the performance. This is just MHO, and - what do I know? ;-)
Regards,
Ilya
I happen to notice that when the search is performed against the modules in the project that do have "PR" part in the extension (i.e. PRG, MPR) the search goes quite fast, whereas search against those having "X" (i.e. SCX, VCX), which are, essentially, tables with Memo fields, goes much slower.
Methinks the Code References function goes record by record in those tables, hence the slowliness of the performance. This is just MHO, and - what do I know? ;-)
Regards,
Ilya
- Thread starter
- #11
Ilya
You might be right, but the speed varies with the same project - somedays quick, somedays slow... The number and type of files doesn't change that much.
B-(
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
You might be right, but the speed varies with the same project - somedays quick, somedays slow... The number and type of files doesn't change that much.
B-(
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
Olaf Doschke
Programmer
If you take your question literally, Griff, you could use the source code in C:\Program Files\Microsoft Visual FoxPro 9\Tools\xsource\VFPSource\foxref and put in SET COVERAGE TO somefile to find out, where the search has it's weakness.
Bye, Olaf.
Bye, Olaf.
- Thread starter
- #13
Mike Lewis
Programmer
Griff, you say that the speed varies with the same project. Have you tried to determine what is different about the times when it runs slowly? For example, are you always searching the same file types? Are you sometimes using regular expressions? Do you ever change any of the options (such as "search only source code and expressions")? Etc?
As with all forms of trouble-shooting, the best approach is to eliminate the variables.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
As with all forms of trouble-shooting, the best approach is to eliminate the variables.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Thread starter
- #15
Hi Mike.
I don't often change any of the settings, I just enter a bit of text that I'm confident will be in the project somewhere - such as ISSUED_ASIN and set it searching. Even searching for the SAME EXPRESSION (as in this particular example) in the same project (on my 'fastest laptop in the world' i7, 8GB RAM) can produce wildly varying speeds.
I thought maybe it was a temporary files thing. If I get five minutes I'll do as Olaf suggests and look at the code.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I don't often change any of the settings, I just enter a bit of text that I'm confident will be in the project somewhere - such as ISSUED_ASIN and set it searching. Even searching for the SAME EXPRESSION (as in this particular example) in the same project (on my 'fastest laptop in the world' i7, 8GB RAM) can produce wildly varying speeds.
I thought maybe it was a temporary files thing. If I get five minutes I'll do as Olaf suggests and look at the code.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
TamarGranor
Programmer
How do you get things done without the Debugger? It's my best friend, letting me walk through code, see values, and much more.
Tamar
- Thread starter
- #17
Easy, don't make mistakes - don't need a debugger.
B-)
Nah, I just put a couple of messagebox calls in the code until I find the problem.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
B-)
Nah, I just put a couple of messagebox calls in the code until I find the problem.
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
Olaf Doschke
Programmer
Most often a breakpoint at the point you now put your messageboxes is more efficient to debug. Give it a try for a whole week, and if you're not satisfied, go back to your usual habits. That's what I would suggest in that matter. Be honest about it. And don't be put aside by visually added brakpoints not working.
Some things you will need to know by heart: Wile in debug mode, you cannot change code, but you can copy code to the command window, ammend it there (eg fix a syntax error) and execute it there, as if it was in the code. That alone can help you go forward in your code without restarting. You can then skip that code in the debugger you executed manually in the command window, by setting the next statement.
You can look at call stack, variables defined, use intellisense on objects and collections within the command window etc etc. And that's all stuff you think is neglectable?
Bye, Olaf.
Some things you will need to know by heart: Wile in debug mode, you cannot change code, but you can copy code to the command window, ammend it there (eg fix a syntax error) and execute it there, as if it was in the code. That alone can help you go forward in your code without restarting. You can then skip that code in the debugger you executed manually in the command window, by setting the next statement.
You can look at call stack, variables defined, use intellisense on objects and collections within the command window etc etc. And that's all stuff you think is neglectable?
Bye, Olaf.
- Thread starter
- #19
Olaf,
Thanks for the advice, but even if I used it for a month I might not use it at all - I don't often even need to do the messagebox("Here") thing very often... The way I develop my code means most is tested as I write it...
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
Thanks for the advice, but even if I used it for a month I might not use it at all - I don't often even need to do the messagebox("Here") thing very often... The way I develop my code means most is tested as I write it...
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
I hope, colleagues you would not object me putting in my another 2 cents? ;-)
Two things may slow down the performance (whether it's Code Ref. search, or any other search through the files on disk, regardless):
1. Automatic updates (I hate them with passion because of that, but that's another topic altogether, let's not elaborate on it here).
2. HDD "energy saving" or "sleep" mode (for the lack of better word, coz memory ain't servin' me well at the moment).
The former lurks behind the scene and, upon arrival via Internet, "intercepts" the HDD and forces it to work for itself all but exclusively. Remedy? Do not log in to the Net unless you mean it.
The latter is the trade off for longer lasting battery in the autonomous mode in laptops: your HDD stops spinning, thus consuming less energy overall; however, once the "request for service" comes from CPU to the HDD - it needs some time to come out from that "sleep" mode, start and accelerate its rotation to gain its normal rotation speed.
Note that the HDD is "the culprit" in both cases. No wonder, however: it is the slowest component in any computer - would not you agree? (
)
Regards,
Ilya
Two things may slow down the performance (whether it's Code Ref. search, or any other search through the files on disk, regardless):
1. Automatic updates (I hate them with passion because of that, but that's another topic altogether, let's not elaborate on it here).
2. HDD "energy saving" or "sleep" mode (for the lack of better word, coz memory ain't servin' me well at the moment).
The former lurks behind the scene and, upon arrival via Internet, "intercepts" the HDD and forces it to work for itself all but exclusively. Remedy? Do not log in to the Net unless you mean it.
The latter is the trade off for longer lasting battery in the autonomous mode in laptops: your HDD stops spinning, thus consuming less energy overall; however, once the "request for service" comes from CPU to the HDD - it needs some time to come out from that "sleep" mode, start and accelerate its rotation to gain its normal rotation speed.
Note that the HDD is "the culprit" in both cases. No wonder, however: it is the slowest component in any computer - would not you agree? (
)Regards,
Ilya
- Status
Similar threads
