This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: recommend use of gperf version 3
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: Bruno Haible <bruno at clisp dot org>
- Cc: gcc-patches at gcc dot gnu dot org, GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: Tue, 7 Jun 2005 18:38:14 +0530
- Subject: Re: recommend use of gperf version 3
- References: <200506061226.39392.bruno@clisp.org> <42A57030.3060309@gmail.com> <200506071340.17837.bruno@clisp.org>
- Reply-to: Ranjit Mathew <rmathew at gmail dot com>
On 6/7/05, Bruno Haible <bruno@clisp.org> wrote:
> Hello Ranjit,
>
> > They should also be tested with Jacks:
> >
> > http://gcc.gnu.org/install/test.html#TOC2
> >
> > There *should not* be any regressions, but you never
> > know...
> >
> > I assume that you bootstrapped and tested for regressions
> > after you applied your patch. Were you able to measure any
> > improvements in performance?
>
> Sorry, I did not do all this (re-bootstrapping, regression-testing, measuring).
I did a rebuild of the Java bits (gcc/java, libjava) once with the
old table and once with the new table (built using gperf-3.0.1
and your command-line options). The build time went
slightly up from 20m 24.850s to 20m 28.315s (~0.2%, that
is noise).
There were no regressions in the testsuite (with Jacks included).
> But I know gperf well enough to be confident in the modified command-line
> options.
I didn't realise you were the co-author of gperf.
> I'm hoping that someone from the GCC developers likes the patch and commits
> it for me, and that the performance change may show up in the automatic
> builds.
Either a global maintainer has to approve it or the
maintainers of the C++ and the Java front-ends have
to approve the respective bits.
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/