[
https://issues.apache.org/jira/browse/DERBY-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134679#comment-13134679
]
Bryan Pendleton commented on DERBY-5474:
----------------------------------------
Well, it was <javac> and <java> tasks that we were forking, so I think it was
definitely JVM forking.
But, it was mostly on Linux boxes. I don't think we had a single Solaris
machine in that build system.
Another thing is that our machines tended to be massively over-provisioned with
real memory, so that
might also make forking fast.
On your laptop, do you have JAVA_OPTS or ANT_OPTS or other parameters that
might control the
virtual memory size of the Ant and/or forked Java processes?
I rather doubt it's worth pursuing my old memories very far. I see no reason
not to remove the forking,
since as you say it was wholly unnecessary. So it can't hurt, and since it
demonstrably helps at least
some environments, I say full speed ahead!
> Speed up message splitting in build
> -----------------------------------
>
> Key: DERBY-5474
> URL: https://issues.apache.org/jira/browse/DERBY-5474
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
> Affects Versions: 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Fix For: 10.9.0.0
>
> Attachments: d5474.diff
>
>
> On a slow machine I sometimes use to build Derby, running the
> org.apache.derbyBuild.splitmessages tool takes 30 seconds and accounts for
> 15% of the total time needed to run "ant -q buildsource" (which builds the
> engine, the network server and the client, but not the tests or demos). The
> tool is invoked 15 times, and each time a new Java process is started because
> the Ant target has specified fork="yes". By changing it to run the
> splitmessages tool in the same Java process as the one running Ant, the time
> is reduced to 3-4 seconds on the same machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
