Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Mike Yearwood
  Where is Mike Yearwood?
 Toronto
 Canada
 Mike Yearwood
 To: Pete Sass
  Where is Pete Sass?
 Marathon, Ontario
 Canada
 Pete Sass
 Tags
Subject: RE: C++ compiler
Thread ID: 415740 Message ID: 416000 # Views: 53 # Ratings: 0
Version: Visual FoxPro 9 SP2 Category: 3rd Party Software
Date: Thursday, December 18, 2014 3:22:37 PM         
   


> >
> > Sorry Pete. Most people do not care how big the exe is. The FoxPro exe is not used the same as a C++ exe. The C++ exe is loaded into RAM for execution. The VFP EXE is opened shared and bits and pieces of it are repeatedly extracted for execution. If the simple loop is not fast, then it stands to reason other things are not going to be fast.
> >
> > Compile optimization is also about changing poorly written code into faster code, not just smaller exes.
> >
> > Mike Yearwood
> > Microsoft MVP Visual FoxPro 2008, 2009
> > We have enough youth. We need a fountain of smart!
> > There may be many ways to skin a cat, but there are very few right ways to do it.
>
>
>
> Hi Mike,
>
> Sounds to me like picking several slow items out of hundreds of good things about the Microsoft C++ compiler
> engine is like throwing the baby away with the bath water!
> However, this is every developers choice to decide. - lol
>
> Since the fault sits with the Microsoft C++ Compiler engine maybe a call to good old Bill would help.
>
> In the mean time I continue to use Microsoft C++ version 10 for some desktop applications and C# for
> web although there are definitely some things in VFP I would much rather work with.
> In the past 2 years I have been forced into C++ and C# development as many of my clients now demand a
> current and fully supported language.
>
> Unfortunately, with most of my application upgrades coming down off of a deployment server and up in northern
> Canada we have very slow Internet download speeds . . . we are still concerned about EXE sizes. I am sure there
> are a lot of others in 3rd world countries and remote location operating on old T1 carriers or worse that are
> also concerned about EXE sizes.
>
>
> On the topic of compilers . . .
> Don't get me wrong, I totally agree that; "optimization is also about changing poorly written code into faster code".
> Optimization is also about shrinking the EXE size; by removing unneeded/uncalled dead code, removing duplicate code,
> tokenization of common calls, etc. This by the nature of the beast will shrink the EXE and impart a speed improvement
> across the entire application. Smaller memory footprint, less memory addressing to handle, no reads to the disk for
> required DLL runtime routines that are not currently in memory, etc.
>
>
> REAL WORLD TEST
> Interestingly enough, I did one more test using a native VFP created EXE versus a VFP C++ created EXE using
> the Microsoft C++ compiler engine.
>
> In this test I performed a process loop to run through 6 millions records with an inside loop to process
> 6 character fields filled with unique 10 character text strings.
> I introduced no indexes and performed a 100% sequential process of all 6 million records. I performed the
> test search on the last record value in field number 3. That means that the unique match would be found
> after looking for a match on 6M records X 3 as each field was processed one field at a time.
> So in this test 18 million string comparisons were done involving and outer and inner process loop.
>
> Interesting enough here are the results and this is a true test as I rebooted my computer and ran the
> VFP test then rebooted my computer and performed the C++ test to 100% ensure nothing cached.
>
>
> VFP NATIVE COMPILED EXE TEST RUN
>
>
>
> C++ TEST RUN
>
>
>
> Of interest here on the above testing the C++ compiler performed the search 4 seconds faster
> or around 9% faster.
>
> I present these test results for 2 reasons.
> 1. You simply cannot pick one test result based upon a process loop that does nothing inside it.
> If one chooses to measure the worth on a compiler based upon this kind of test well I guess they
> can do as they wish.
> 2. When you get into a 18 million loop process to obtain a meaningful time measurement, I think that
> bringing speed differences into the mix at this point is meaningless.
>
> I 100% believe that to conclude . . .
> "If the simple loop is not fast, then it stands to reason other things are not going to be fast."
> is a generalized opinion statement and everyone is entitled to their own option.
>
>
> Anyways, I am not going to debate the pros and cons of other compilers as the entire subject is relative to what
> a developers needs to do as they try to balance product needs, speed needs, development time and cost.
>
>
> Pete "the IceMan", from the Great White North of Canada.
> www.marathongriffincomputers.com

I care about EXE size. I've long been a proponent of single or few classes per classlib and single UDF per prg. That is intended to increase re-use and reduce un-needed things in the exe. It also increases speed. You're missing my point. How does VFP do an empty loop faster than C++? I was convinced C++ would regularly beat VFP in every task - because VFP is a layer removed from C++.

Mike Yearwood
Microsoft MVP Visual FoxPro 2008, 2009
We have enough youth. We need a fountain of smart!
There may be many ways to skin a cat, but there are very few right ways to do it.

ENTIRE THREAD

C++ compiler Posted by Mike Yearwood @ 12/11/2014 9:47:42 PM
RE: C++ compiler Posted by Tony Vignone @ 12/11/2014 10:18:16 PM
RE: C++ compiler Posted by michael johnson @ 12/12/2014 3:15:14 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/12/2014 4:40:18 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/12/2014 8:01:24 AM
RE: C++ compiler Posted by Pete Sass @ 12/12/2014 12:41:53 PM
RE: C++ compiler Posted by Pete Sass @ 12/13/2014 5:29:47 PM
RE: C++ compiler Posted by Tony Vignone @ 12/13/2014 8:27:53 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/14/2014 3:44:09 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/15/2014 4:02:35 PM
RE: C++ compiler Posted by Tony Vignone @ 12/16/2014 2:10:42 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/16/2014 6:00:18 PM
RE: C++ compiler Posted by Tony Vignone @ 12/16/2014 7:37:14 PM
RE: C++ compiler Posted by Pete Sass @ 12/17/2014 3:27:15 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/17/2014 3:50:23 PM
RE: C++ compiler Posted by Pete Sass @ 12/17/2014 6:09:24 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/18/2014 3:22:37 PM
RE: C++ compiler Posted by Pete Sass @ 12/18/2014 4:55:58 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/18/2014 7:16:44 PM
RE: C++ compiler Posted by Pete Sass @ 12/18/2014 7:53:51 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/19/2014 12:48:30 AM
RE: C++ compiler Posted by Pete Sass @ 12/19/2014 11:57:43 PM
RE: C++ compiler Posted by Mike Gagnon @ 12/20/2014 2:09:13 AM
RE: C++ compiler Posted by Pete Sass @ 12/20/2014 3:18:09 PM
RE: C++ compiler Posted by Vilhelm-Ion Praisach @ 12/20/2014 6:53:41 PM
RE: C++ compiler Posted by Pete Sass @ 12/20/2014 8:25:14 PM
RE: C++ compiler Posted by Vilhelm-Ion Praisach @ 12/20/2014 9:18:10 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/22/2014 3:01:11 PM
RE: C++ compiler Posted by Pete Sass @ 12/22/2014 3:57:28 PM
RE: C++ compiler Posted by Vilhelm-Ion Praisach @ 12/22/2014 5:54:52 PM
RE: C++ compiler Posted by Mike Yearwood @ 12/22/2014 9:38:06 PM
RE: C++ compiler Posted by Chuanbing Chen @ 12/23/2014 1:03:49 AM
RE: C++ compiler Posted by Mike Yearwood @ 12/22/2014 3:42:43 PM