0

I have an external excel file which contains a list of different parameter values needed in order to run an application. One of the parameters in the excel file is, numberofcustomers. I read this at the beginning of my program into an object, say, globalconstant object, gcs. The class globalconstant has a private data member int Numberofcustomers;

Whenever I have to use this parameter in my program, I access this via a public member function of the class defined thus:

int numberofcustomers() const {return Numberofcustomers;}

For instance, if I have to loop through the number of customers, I have:

for(int i = 0, sz = gcs.numberofcustomers(); i < sz; i++){...}

Thus, the compiled and built executable has no idea what numberofcustomers could be.

As opposed to this, another design could be to explicitly define:

static const int numberofcustomers = 100;

in a header file and recompile/rebuild the entire project. This way, I can completely do away with the need of the external excel settings file.

Are there any compiler optimizations I am missing out on by having the first design (store parameter values in excel file that is read in during run time) as opposed to the second design (store parameter values in the source code itself)? It appears to me that the second design should benefit from benefits since it knows how many number of customers are there in the problem before run time itself.

The number of different parameters I have are 15 to 20 or so. The benefit of the first design is that it is much easier to manage the parameters by opening just the excel file and modifying it. It also saves me from the hassle of recompiling and rebuilding my project.

Tryer
  • 3,580
  • 1
  • 26
  • 49
  • Please, don't put configuration parameters into Excel sheets. Create a separate text configuration file. – wilx Sep 20 '18 at 05:39
  • @wilx Yes, I store it as a space delimited text file from the C++ project POV. I just have it named using .xls extension so that within Windows, I can open it via Excel. – Tryer Sep 20 '18 at 05:40
  • I'd have to disagree with the space-delimited text file, because inventing your own file format is bad. Use a well-known metaformat to store your configuration data, like JSON, INI, XML or Excel, in order of decreasing preference. None of this adresses the question though. – Ulrich Eckhardt Sep 20 '18 at 05:45
  • I've finding this post quite hard to believe. Is optimization really an issue here? Is it really the most important issue? Have you done any timings to see if there is any significant difference between the two approaches? Surely the flexibilty of storing signifcant parameters to your program in an external source is what matters. – john Sep 20 '18 at 05:45
  • @john I had a previous experience where the release build (within Visual studio) with optimization turned on completely ended up with a significant improvement because it explicitly knew the parameter value. Please see https://stackoverflow.com/questions/48779081/kcachegrind-output-for-optimized-vs-unoptimized-builds – Tryer Sep 20 '18 at 05:49
  • Using that for the number of customers seems like nonsense, because that number usually changes over time. Anyhow, the term you are looking for is "constant propagation", which is the compiler optimization that you can do with compile-time constants. Explaining that here is a bit too broad though. – Ulrich Eckhardt Sep 20 '18 at 05:53
  • @UlrichEckhardt Thanks, I will look into it. With the first design, (reading in from excel file), is it true that constant propagation optimization is impossible? – Tryer Sep 20 '18 at 05:55
  • @Tryer You have the advantage over because I have no idea about your app but the key word you used is signifcant. How are you judging that any optimization gain is signifcant? Seems to me you are interested in this topic in abstract (nothing wrong with that of course) rather than as a practical matter. – john Sep 20 '18 at 06:05
  • @john My work is not for a production release of a commercial app where recompilation/rebuilding is an issue. That case, I agree that the benefit of excel file maintenance is more important. I work in academic Operations Research work, where we have to get the code to run quicker for a difficult NP Hard problem as compared to solving it using a general purpose off-the shelf integer programming solver (such as CPLEX). Hence, the query. In my case, recompilation/rebuilding time is not too much of an issue. – Tryer Sep 20 '18 at 06:09
  • 1
    Imagine you have to implement a complicated mathematical algorithm with some variables. You can implement it with variables which are read from a configuration at start of program. Alternatively, you can set variables as constant values in your program. The latter might be strong optimized as the compiler may recognize that all expressions can be solved at compile time. So, the code is reduced to output of final result (and nothing else). Very good performance! The only problem the latter solution has: It's not flexible at all - just supports one specific configuration of variable values. – Scheff's Cat Sep 20 '18 at 06:10
  • @Scheff Yes, that is precisely where I am using the code. My applications are for specific OR problems. So, recompilation/rebuilding is not too much of a pain (it takes 1 minute or so). I mean, I have to report solution times for number of customers = 50/100 and so on, so it seems better to have an inflexible executable built each time for n = 50, then another for n = 100 and so on. – Tryer Sep 20 '18 at 06:11
  • The balance between the former and latter extremes is a design decision which may be responsible for success or fail of your product. This has to be done carefully (and it's not a shame to discuss this with sales personal, beta testers, and customers...) ;-) – Scheff's Cat Sep 20 '18 at 06:13

0 Answers0