Saving a job that has thousands of builds in its history takes several minutes for the operation to complete.

From a few jstack dumps I took during the operation it seems that the thread handling my job’s configSubmit operation takes a very long time to perform org.jvnet.hudson.plugins.DownStreamProjectActionFactory.createFor(DownStreamProjectActionFactory.java:69).

Looking at the code of DownStreamProjectActionFactory.java I’ve seen the following:
// add the DownstreamBuildViewAction to all run builds, DownstreamBuildViewRunListener will append this to the others.
final List<?> builds = (List<?>) target.getBuilds();
for (Object object : builds) {
final AbstractBuild<?, ?> build = (AbstractBuild<?, ?>) object;
final List<DownstreamBuildViewAction> dBuildViewAction = build.getActions(DownstreamBuildViewAction.class);
if (dBuildViewAction.size() == 0)

{ final DownstreamBuildViewAction downstreamBuildViewAction = new DownstreamBuildViewAction(build); build.addAction(downstreamBuildViewAction); LOG.fine("Adding " + downstreamBuildViewAction + " to " + build); }

else

{ LOG.fine(build + " already has " + dBuildViewAction); }

LOG.fine(build + ":" + build.getActions());

It seems like the plugin is going through ALL the builds and tries to add the downstreamBuildViewAction to each build where it’s missing.
Furthermore, it’s logging the operation regardless of whether the build.addAction is performed or not.

Assuming that in most of the builds in the history adding the dBuildViewAction was already done at least once, why “bother” and log that every time the project is saved? It's not doing any operation besides logging it...

When the build history is huge (as is my case) it’s just takes a very long time to log unnecessary information...

So my suggestion is to remove to following lines:
else {
LOG.fine(build + " already has " + dBuildViewAction);

See attached BB_CONT_MICRODUS_lrat-jstack.txt which contains jstack snippets while the job was being saved.