More use of inline and less of virtual thunks - especially with Clp

[jjhforrest]

Profiling Cbc I notice a large number of "virtual thunks" to OsiClp. This is an overhead and also may prevent the code being better optimized. So I intend to go on a slow journey to try and improve this.

There will be pauses after each "improvement" to make sure nothing has been broken.

The first change is relatively simple and designed to reduce the use of isInteger and similar. There is a call - getColType which sets up an array (char *) with 0,1 or 2 - 0 continuous, 1 binary, 2 general. This is virtual but then that array can be used many many times.

As my first test I have changed all Cgl functions to use getColType.

Please inform me of any problems - before I make the next step.

[jhmgoossens]

Could you push an empty commit to Cbc master to trigger the Cbc build and test Actions to run with the updated code of Cgl, Clp or other related repositories?

The Cbc build and test Actions are great, but they don’t get automatically triggered on commits in related repositories, unfortunately—only commits to Cbc itself.

(Alternatively, I can make the Actions manually triggerable, to not need the empty commits. But that seems more work to remember to trigger each.)

[tkralphs]

It should be possible to set up our Actions such that commits to dependencies trigger an Action in the parent project. Either that or we could also set up a cron job in Cbc that checks nightly for changes to other projects. These are just ideas and would require some up front investigation but could save time and headaches down the road.

[tkralphs]

Hey @jjhforrest, could I convince you to do these improvements in a branch and open an associated pull request? This is a textbook case for when developing in a branch is very useful and this would keep all the related commits together. Of course, the disadvantage is that only people who specifically try the branch will be testing the improvements, not just anyone who is working with the tip of master. Still, maybe you could work in a branch and merge to master periodically so that we have all the related commits together.

[jjhforrest]

I will think a bit longer. As you point out - the disadvantage is people will not use modifications.