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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Performance problem 4

Status
Not open for further replies.

jamesrav

Programmer
Sep 17, 2017
29
MX
I have about 90,000 dbf files in a single folder. They contain from 0 to 100 records, but generally 5-20. I have a .prg file that cycles thru all the tables and does some processing based on contents. The problem/puzzle is that sometimes this .prg file can go thru all 90,000 in about 1 minute, and other times it can take 15 minutes. No change to the .prg at all. I've checked the task manager and it's not the case that the CPU is occupied by other processes when the .prg is functioning slowly. It just seems that VFP in some situations 'knows' about the tables and can move thru them quickly, and in other cases it is seeing the data for the first time (and I should add that I cycle thru the 90,000 multiple times with different criteria, and when it's operating well, the 1 minute time is consistent , and when slow, it's 15 minutes every time thru - never improves). So is this a VFP issue or Windows in general? I've tried adding some Sys() commands at the start (based on the Help file) but it does not improve things.
 
By the way I realize my idea of working on it in a more recent Visual Studio and targetting the 7.1 runtime doesn't work out for multiple reasons. So double thank you, Rick.

Chriss
 
You're welcome.

If there are any additional extensions you'd like to see added to VFPx, let me know. I'll see what I can do.

--
Rick C. Hodgin
 
Mike, the FLL is included in the ZIP file I attached to my post above.

To teach you about me: I viewed you as a raging attacker in the posts above, and also these new posts as well. So, I will just let you go about your rage venting. When you're all finished with that, consider if you've improved anyone's life in so doing.

--
Rick C. Hodgin
 
And Mike, if there's any additional extension or functionality you'd like added to VFPx please let me know. My offer to add functionality was blanket to everyone.

--
Rick C. Hodgin
 
Mike, again you made a fool of yourself by not looking into the attachment. Pity.
On the positive side, you're not excluded, are you? Perhaps next time, think twice before you spray your anger. I stopped taking this serious, but it's still sickening, calm down. Have more respect towards anyone but yourself.

Rick, you explicitly used VS2003. In the meantime I learned about command line developer prompt, which even allows targeting the mscvrt.dll (literally), With some legacy project I could even just use NMake. Have you ever worked with this command prompt and know more about it and its capabilities?

Chriss
 
Yes. You can also use VS2019 and install the newer MS C runtime and gain all modern security and performance enhancements.

[link url=https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-160]Latest VC Redistributables[/url]

I've seen several projects released in old versions of Visual Studio to accommodate everyone's needs. I always try to make my software able to run in Vidual Studio 2003, and Windows 2000 Professional. But also test in Visual Studio 2019 and Windows 10.

--
Rick C. Hodgin
 
I have 2019 and the 2022 preview, so I have latest VC redistributables, the problem rather is compiling not only to x86 (32 bit), but also to let the resulting DLL (FLL) only depend on msvcrt71.dll.
Even if migration of the sln would work. So assume I start a sln from scratch in VS2019, could I target msvcrt71.dll as a "platform"?



Chriss
 
If you install that VC Redistributable on any target machine that will run the FLL, it should work with VFP and without issue. The C runtime is part of a standard, so whereas VFP targets its version, and the FLL targets its version, they should cohabitate without issue and be fully compatible where data is processed in one and passed to the other.

I don't remember what version the VS2019 MSC runtime is, but I use it with my DLL's and no issue across a wide array of machines and OS versions.

You should be able to load the VS2003 solution and migrate it to the current toolset.

--
Rick C. Hodgin
 
Rick said:
You should be able to load the VS2003 solution and migrate it to the current toolset.

Well, I did that and it has a long migration report about problems, I couldn't get that to work.

In general, I know I can simply provide another C++ runtime dll to let declare or set library work. It would still be nice to not need another runtime. I know, the era of RAM shortage is past, so I shouldn't care. It's one of the positive features of VFPX -it can compile to use more recent C++ runtimes, too.

I'm just like Mike Yearwood in respect to buying the VFP C++ compiler to see what it actually does. I don't get connected to your freepro site, but I'd also like to consider doing my own language which may not even have to have a lot in common with VFP and I discovered GraalVM and Truffle:
As JS, Ruby, Python and R have been done, this can even allow cross-language implementations all running in one VM and you can even dbug polyglot applications with
Maybe take a look into that.

Chriss
 
If you have an MSDN account, you should be able to download and install Visual Studio 2003 and get a copy of Windows 2000 Professional or Windows XP Professional for development.

Let me see if I can get it to compile by upgrading to VS2019.

--
Rick C. Hodgin
 
Thanks, Rick.

I think I also could do better when adding the LCK files to the solution before opening and migrating it. I realize they are excluded from redistribution and so you have to add them from the samples API folder and then the migration may work.

So I'm also at it, while you're at it.

Chriss
 
To get it to compile in VS2019, I had to do these steps:

1. I had to set the include directory to include the pro_ext.h provided by Visual FoxPro in the VS2019 project on the Debug and Release (Right-click "vfp2c32" project, properties, C/C++, General, Additional Include Directories):
Code:
C:\Program Files (x86)\Microsoft Visual FoxPro 9\Samples\API

2. I had to set the Additional Library Directories to include the VFP winapims.lib library (Right-click "vfp2c32" project, properties, Linker, General, Additional Library Directories):
Code:
C:\Program Files (x86)\Microsoft Visual FoxPro 9\Samples\API

3. I had to add Preprocessor directives (Right-click "vfp2c32 project, properties, C/C++, Preprocessor, Preprocessor Definitions):
Code:
_ALLOW_RTCc_IN_STL;WINDOWS_IGNORE_PACKING_MISMATCH;_CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;

4. I had to add an additional library to include support for _vsnwprintf_s() (Right-click "vfp2c32" project, properties, Linker, Input, Additional Dependencies):
Code:
legacy_stdio_definitions.lib

UPDATED: 5. Turn off SAFESEH (Right-click "vfp2c32" project, properties, Linker, Advanced, Image Has Safe Exception Handlers):
Code:
No (/SAFESEH:NO)

6. And in my personal copy, I also modified the post build even to copy to my temporary test folder where I was testing the FLL's functionality.
Code:
  Debug:  copy "$(IntDirFullPath)vfp2c32d.fll" "c:\temp\$(TargetName).fll"
Release:  copy "$(IntDirFullPath)vfp2c32.fll" "c:\temp\$(TargetName).fll"

After all that it compiled. Press F7 to do a build.

--
Rick C. Hodgin
 
Mike Yearwood said:
I'm working on a Saturday and the company bought pizza. Not even the person I work with on this project, who got pizza thought to mention it to me. That is how humanity operates.

Mike, you come across as hostile and mean. If you're like that in real life as well to your online presence, then people won't want to be around you or involve you in things.

You claim humanity is a particular way. And you're right they can be. From my perspective, you're part of that "humanity" you despise because you come across as mean, hostile, attacking, biting. If you want to change, there's a path to change. It require conscious effort and a true desire to change from within.

-----
The FLL is attached to my posts above in this thread. It's the little link under the post. It's kind of hidden and easy to overlook IMO.
Download FLL + source code changes

--
Rick C. Hodgin
 
Rick,

I have gone the path of first converting to VS2017, then VS2019 and finally VS2022 Preview and that worked fine with the migration of the solution, after several upgrades and SDK installations for STL and MFC that were missing.

I almost have had all compiler warnings and errors to add several compiler and linker options. Thanks for listing everything you needed to do, I now only need to add _CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS, add the legacy_stdio_definitions.lib and then should also get rid of the last build error I have about _vsnwprintf_s()

I changed the linker option /SAFESEH to /SAFESEH:NO, but maybe should instead should handle that problem with _CRT_SECURE_NO_WARNINGS;_WINSOCK_DEPRECATED_NO_WARNINGS;

I think now I'm ready for a bit of C++,
thanks Rick.

Chriss
 
Mr Yearwood,

you've been told what to download multiple times. Yes the changed FLL is not in the GitHub repository. But that has its own reasons you better should know as the professional developer you are. Concentrate on what's been told, not what you interpret into mistakes of others that are only your own mistakes, literally, taken wrongly. If you still don't find the FLL anywhere, I'll point it out, but there are enough pointers, if you just would be as thorough as you always claim to be. Paying attention doesn't cost money nor ego.

Just by the way, I don't look down on you just because you make several mistakes, I just would like to help you see them and grow from them, but you still insist on having the perfect height. You're a good developer, I'm not afraid to say better than all of us in VFP, but you show a lack of attention and a lack of understanding anything else but FoxPro.

Anybody might red-flag this, too. I'm just 1:1 with you in return what you do based on false assumptions. I know what I promised, but you need feedback and if nobody cares to give it a try from time to time you'll never have the chance to reflect and change. I know, you're sure only everybody else has to change. Well, you're free to be wrong, it's all just up to you.

Chriss
 
Adirex('c_files','C:\Windows\CSC\*.*') gives me an Access denied prompt with both FLL versions.

No idea how you got version 2.0.0.19 from Christian to not error.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top