Does anyone know why Code References Search is sloooooow sometimes?

[GriffMG]

I love this feature, but sometimes it's like it is walking through treacle... and other times it's whiz...

Any ideas?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Koen Piller]

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:

http://vfpx.codeplex.com/wikipage?title=GoFish

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)

 

[GriffMG]

That's worth knowing

Thank you

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[TamarGranor]

My experience is that when the Debugger is open, Code References is very slow.

Tamar

 

[GriffMG]

Debugger? What's that for? B-)

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]

My experience is that when the Debugger is open, Code References is very slow.

My experience is that when the Debugger is open, everything is very slow.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[GriffMG]

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.

 

[Mike Lewis]

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

 

[GriffMG]

No nothing, even tried rebooting... odd behaviour

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[IlyaRabyy]

Would you mind terribly, colleagues, if I put in my 2 cents?
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

 

[GriffMG]

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.

 

[Olaf Doschke]

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.

 

[GriffMG]

Never thought of looking at the source code!

Good Idea Olaf

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]

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

 

[GriffMG]

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.

 

[TamarGranor]

I don't use the debugger, so it can't be that.

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

 

[GriffMG]

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.

 

[Olaf Doschke]

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.

 

[GriffMG]

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.

 

[IlyaRabyy]

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