Use std algorithm instead of simple loop to fill MVA inputs. Faster...

Backport one change from !89 (closed) which is to fill the input vector using an STL algorithm instead of a simple loop, as this gives a nice speed improvement. The rest of that MR, to replace virtual methods with type erasure, is on hold as currently is slower (based on gcc 4.9).

Maybe we should advertise this pattern, i.e. the fact that std::transform beats a 'raw loop' -- and that it makes sense anyway in view of the future, with eg. parallel STL coming to C++17 (see specifically clause 2 and 4 of http://en.cppreference.com/w/cpp/algorithm/transform, or more generally, http://en.cppreference.com/w/cpp/experimental/parallelism).

Yes, I think its worth advertising the fact people should try and use stl algorithms where they can (and once you start thinking about it, given the range available and the very flexible lambda functions, a lot of use cases can be converted, even quite complex ones). However, its not clear that you will always win (straight away) in speed, its probably use case specific. As always, the only way to know is to profile. In this case for instance I wonder if the speed comes from the fact I remove the 'i' iterator, more than anything else, and if some other 'simple' loop implementation without it could do better.

I think though, regardless, as to if a use case wins now using stl algorithms more is likely to gain in the future with parrallel stl etc., as then we are utilising the work done by the stl library maintainers (who know what they are doing). So yes, in short we should promote using them as much as possible, I would say.

Status changed to merged

mentioned in commit 111c3103

@jonrob I wonder if this change is the cause of the problem with the centos7 build that we have been seeing in the last week or so? https://lhcb-archive.cern.ch/artifacts/nightly/lhcb-gaudi-head/1157/summaries.x86_64-centos7-gcc49-opt/Rec/build_log.html

Ermm... I don't immediately see why (and this isn't the first use of std::transform in our code). Its a pretty basic usage...

We can try reverting it, just as a test, if you want ?

googling around for 'fatal error: malformed or corrupted AST file' I see nothing that would relate to this change. More things related to cache errors, and a few discussion for root, such as

https://root.cern.ch/phpBB3/viewtopic.php?t=17325

could it be a root problem ?

Adding @clemenci. I don't think it can be a Root problem, since this was working some time ago and Root version has not changed. Something is breaking the genconf step.

Is it really coming from the genconf step ? To me it looked like the first error was during the library linking, with genconf subsequently failing as a secondary effect.

Annoyingly, I cannot reproduce it on lxplus7. @clemenci any ideas?

A lot of the discussions relating to the error I can find seem to talk about caches. Are the nightlies using ccache ? If so, could the cache for the centos7 build machine be cleared ?