[Os-project-managers] Question about OSxLParserdata, OSInstance, OSOption
Horand Gassmann
Horand.Gassmann at Dal.Ca
Tue Dec 21 06:52:35 EST 2010
Kipp Martin <kmartin at chicagobooth.edu> wrote:
> Hi Gus:
>>
>> I probably should have asked this long ago, but I never really took
>> everything on board and then I forgot.
>
> First, a generic comment. One I have made before. OS is a project
> evolving over time. Much of what you see in OSInstance was written
> four years ago. My guess is that if you were to work on the OSoL
> parser four year from now you might do things differently. The OS
> constitution was not written on day 1 and then adhered to from day 1
> over time. It evolved and is evolving. We are constantly learning
> new and better ways to do things. I knew almost no C++ when I first
> started OS.
>
> Now, with regard to the m_mxxx. Let's take as an illustration,
> m_mdVariableLowerBounds. Remember, Object Orient Programming makes
> things SLOW. There is definitely a performance hit. Indeed we are
> really getting clobbered with this in the nonlinear part of our
> code. So let's look at for example, the method to get the variable
> lower bounds. Here it is:
>
>
> double* OSInstance::getVariableLowerBounds() {
> processVariables();
> return m_mdVariableLowerBounds;
> }//getVariableLowerBounds
I agree that this is faster. But remember what I wrote earlier about
the danger of memory pollution? If you give the user access to your
memory in this way, you run the risk that they overwrite your memory.
I do not consider this safe.
> Look how efficient and fast it is. You are just returning a
> C-pointer to a chunk of memory. You don't have to go through the
> nonsense of looping over multiple objects like this:
>
> instanceData->variables->var[i]->lb;
>
> for each i. Ouch, the above is going to be comparatively slow.
> Memory is cheap. Why not duplicate in-memory the variable lower
> bounds so they can accessed more efficiently? Now let's say you
> want to get this information over and over again many times. Using
> the m_mdVariableLowerBounds is going to the be the most efficient
> way to do this. Right now I am trying to finish up a project for the
> Cincinnati folks that involves decomposition and branch and price. I
> am constantly accessing row and variable upper bounds and resetting
Aha!!! Do you really trust the user to do this right? And at what
point do you get out of sync between instanceData->variables->var and
m_mdVariableLowerBounds? I think this is an accident waiting to happen.
Cheers
gus
> them. Working directly with pointers that have the information in
> memory is the most efficient way to do this.
>
> Jun -- anything to add?
>
> Cheers
>
>
>>
>> Only today do I realize (again) that there is quite a difference in
>> the things that are being stored in OSInstance and OSOption.
>> OSInstance stores the entire instance into arrays and things and
>> then duplicates everything into the OSInstance object. This seems
>> wasteful to me, so I have in the OSoL parser been far more
>> conservative and stored _nothing_ into m_mi... things. I store
>> stuff into OSoLParserdata temporarily, and then copy them into the
>> OSOption instance, upon which I will free the temporary storage in
>> OSoLParserdata. OSResult and OSrLParserdata do things that way,
>> too, and maybe that is where I picked up my habits.
>>
>> I hope I am respecting the constitution. (I have not found anything
>> about it in the statutes, so I am not sure.)
>>
>> Cheers
>>
>> gus
>>
>>
>>
>> _______________________________________________
>> Os-project-managers mailing list
>> Os-project-managers at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/os-project-managers
>
>
> --
> Kipp Martin
> Professor of Operations Research
> and Computing Technology
> Booth School of Business
> University of Chicago
> 5807 South Woodlawn Avenue
> Chicago, IL 60637
> 773-702-7456
> kmartin at chicagobooth.edu
> http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
> http://projects.coin-or.org/OS
>
>
More information about the Os-project-managers
mailing list