You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Fedotov <al...@gmail.com> on 2008/03/05 22:31:59 UTC
[classlib][archive] +3.25% on Eclipse startup after a bit of cleaning Was: java.util.jar specialists/authors wanted to clarify manifest chunks
Dear committer,
I've finally got some justification that my patches for HARMONY-4569
are worthy to be committed, see subj. Could you please take a look?
Thank you in advance.
BTW1. Volunteers are welcome to fix TODO comments cleaning the code
and probably getting even more speed up.
BTW2. I just have got another idea: implementing Utf8StringHashMap
collection which would save space by storing a lot of English strings
in Utf8 byte arrays and encode/decode them during rare access
operations.
On Wed, Feb 13, 2008 at 8:01 PM, Alexei Fedotov
<al...@gmail.com> wrote:
> Hello folks,
>
> Do we have original
> working_classlib/modules/archive/src/main/java/java/util/jar/ module
> contributors on board? Could anyone clarify the reasons behind heavy
> solution to copy manifest chunks into a separate hash table descried
> at HARMONY-4569? Aren't entity hash table the only object which should
> be populated?
>
> --
> With best regards,
> Alexei
>
> [1] http://issues.apache.org/jira/browse/HARMONY-4569
>
--
With best regards,
Alexei
Re: [classlib][archive] zlib performance (was: Re: [classlib][archive] +3.25% on Eclipse startup after a bit of cleaning)
Posted by Alexei Fedotov <al...@gmail.com>.
Thanks, Mark!
On Thu, Mar 13, 2008 at 6:30 PM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> I've not tried it but I suspect that refactoring the code to use
> inflateBack (rather than inflate) might also give a significant speedup.
>
> -Mark.
>
>
>
> On 12 March 2008 at 13:33, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > Alexei,
> >
> > Your message reminded me that I had noticed that my debian packages
> > for M5 - which use -Dhy.local.zlib=true - have better performance for
> > inflate/deflate than the M5 releases. Given that we are unlikely to
> > need to debug into the zlib code, perhaps we should *always* compile the
> > zlib code with optimizations. After all it isn't really "our" code, we
> > are unlikely to change it and it hasn't changed since 2005.
> >
> > Debian compile with -O3 and with -DUNALIGNED_OK (on x86 and x86_64) and
> > my tests with minigzip show that these are reasonable choices.
> >
> > I would expect that this would improve eclipse startup performance.
> >
> > -Mark.
> >
> >
> > On 6 March 2008 at 0:31, "Alexei Fedotov" <al...@gmail.com> wrote:
> > > Dear committer,
> > > I've finally got some justification that my patches for HARMONY-4569
> > > are worthy to be committed, see subj. Could you please take a look?
> > > Thank you in advance.
> > >
> > > BTW1. Volunteers are welcome to fix TODO comments cleaning the code
> > > and probably getting even more speed up.
> > >
> > > BTW2. I just have got another idea: implementing Utf8StringHashMap
> > > collection which would save space by storing a lot of English strings
> > > in Utf8 byte arrays and encode/decode them during rare access
> > > operations.
> > >
> > > On Wed, Feb 13, 2008 at 8:01 PM, Alexei Fedotov
> > > <al...@gmail.com> wrote:
> > > > Hello folks,
> > > >
> > > > Do we have original
> > > > working_classlib/modules/archive/src/main/java/java/util/jar/ module
> > > > contributors on board? Could anyone clarify the reasons behind heavy
> > > > solution to copy manifest chunks into a separate hash table descried
> > > > at HARMONY-4569? Aren't entity hash table the only object which should
> > > > be populated?
> > > >
> > > > --
> > > > With best regards,
> > > > Alexei
> > > >
> > > > [1] http://issues.apache.org/jira/browse/HARMONY-4569
> > > >
> > >
> > >
> > >
> > > --
> > > With best regards,
> > > Alexei
> > >
> >
>
>
>
--
With best regards,
Alexei
Re: [classlib][archive] zlib performance (was: Re:
[classlib][archive] +3.25% on Eclipse startup after a bit of cleaning)
Posted by Mark Hindess <ma...@googlemail.com>.
I've not tried it but I suspect that refactoring the code to use
inflateBack (rather than inflate) might also give a significant speedup.
-Mark.
On 12 March 2008 at 13:33, Mark Hindess <ma...@googlemail.com> wrote:
>
> Alexei,
>
> Your message reminded me that I had noticed that my debian packages
> for M5 - which use -Dhy.local.zlib=true - have better performance for
> inflate/deflate than the M5 releases. Given that we are unlikely to
> need to debug into the zlib code, perhaps we should *always* compile the
> zlib code with optimizations. After all it isn't really "our" code, we
> are unlikely to change it and it hasn't changed since 2005.
>
> Debian compile with -O3 and with -DUNALIGNED_OK (on x86 and x86_64) and
> my tests with minigzip show that these are reasonable choices.
>
> I would expect that this would improve eclipse startup performance.
>
> -Mark.
>
>
> On 6 March 2008 at 0:31, "Alexei Fedotov" <al...@gmail.com> wrote:
> > Dear committer,
> > I've finally got some justification that my patches for HARMONY-4569
> > are worthy to be committed, see subj. Could you please take a look?
> > Thank you in advance.
> >
> > BTW1. Volunteers are welcome to fix TODO comments cleaning the code
> > and probably getting even more speed up.
> >
> > BTW2. I just have got another idea: implementing Utf8StringHashMap
> > collection which would save space by storing a lot of English strings
> > in Utf8 byte arrays and encode/decode them during rare access
> > operations.
> >
> > On Wed, Feb 13, 2008 at 8:01 PM, Alexei Fedotov
> > <al...@gmail.com> wrote:
> > > Hello folks,
> > >
> > > Do we have original
> > > working_classlib/modules/archive/src/main/java/java/util/jar/ module
> > > contributors on board? Could anyone clarify the reasons behind heavy
> > > solution to copy manifest chunks into a separate hash table descried
> > > at HARMONY-4569? Aren't entity hash table the only object which should
> > > be populated?
> > >
> > > --
> > > With best regards,
> > > Alexei
> > >
> > > [1] http://issues.apache.org/jira/browse/HARMONY-4569
> > >
> >
> >
> >
> > --
> > With best regards,
> > Alexei
> >
>
Re: [classlib][archive] zlib performance
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> Your message reminded me that I had noticed that my debian packages
> for M5 - which use -Dhy.local.zlib=true - have better performance for
> inflate/deflate than the M5 releases. Given that we are unlikely to
> need to debug into the zlib code, perhaps we should *always* compile the
> zlib code with optimizations. After all it isn't really "our" code, we
> are unlikely to change it and it hasn't changed since 2005.
+1
> Debian compile with -O3 and with -DUNALIGNED_OK (on x86 and x86_64) and
> my tests with minigzip show that these are reasonable choices.
On Windows we are compiling fdlibm with "-Oityb1" which means:
i = enable intrinsic functions
t = favor code speed
y = enable frame pointer omission
b1 = inline expansion level=1
whereas on zlib we are using the default compiler args "-Zi -Od"
Zi = enable debugging information
Od = disable optimizations
> I would expect that this would improve eclipse startup performance.
I would expect it improves all start-up performance since we also have
to read our own JARs.
Unless anyone objects I'll change the ARCHIVE makefiles to always
optimize zlib:
> Index: src/main/native/zlib/unix/makefile
> ===================================================================
> --- src/main/native/zlib/unix/makefile (revision 634609)
> +++ src/main/native/zlib/unix/makefile (working copy)
> @@ -17,6 +17,9 @@
> # Makefile for module 'zlib'
> #
>
> +# Always build in release mode
> +HY_CFG=release
> +
> include $(HY_HDK)/build/make/defines.mk
>
> ZLIB_DIST=../../zlib_dist/# Path to zlib
> Index: src/main/native/zlib/windows/makefile
> ===================================================================
> --- src/main/native/zlib/windows/makefile (revision 634609)
> +++ src/main/native/zlib/windows/makefile (working copy)
> @@ -17,6 +17,9 @@
> # Makefile for module 'zlib'
> #
>
> +# Always build in release mode
> +HY_CFG=release
> +
> !include <$(HY_HDK)\build\make\defines.mak>
>
> LIBBASE=hyzlib
Regards,
Tim
[classlib][archive] zlib performance (was: Re: [classlib][archive]
+3.25% on Eclipse startup after a bit of cleaning)
Posted by Mark Hindess <ma...@googlemail.com>.
Alexei,
Your message reminded me that I had noticed that my debian packages
for M5 - which use -Dhy.local.zlib=true - have better performance for
inflate/deflate than the M5 releases. Given that we are unlikely to
need to debug into the zlib code, perhaps we should *always* compile the
zlib code with optimizations. After all it isn't really "our" code, we
are unlikely to change it and it hasn't changed since 2005.
Debian compile with -O3 and with -DUNALIGNED_OK (on x86 and x86_64) and
my tests with minigzip show that these are reasonable choices.
I would expect that this would improve eclipse startup performance.
-Mark.
On 6 March 2008 at 0:31, "Alexei Fedotov" <al...@gmail.com> wrote:
> Dear committer,
> I've finally got some justification that my patches for HARMONY-4569
> are worthy to be committed, see subj. Could you please take a look?
> Thank you in advance.
>
> BTW1. Volunteers are welcome to fix TODO comments cleaning the code
> and probably getting even more speed up.
>
> BTW2. I just have got another idea: implementing Utf8StringHashMap
> collection which would save space by storing a lot of English strings
> in Utf8 byte arrays and encode/decode them during rare access
> operations.
>
> On Wed, Feb 13, 2008 at 8:01 PM, Alexei Fedotov
> <al...@gmail.com> wrote:
> > Hello folks,
> >
> > Do we have original
> > working_classlib/modules/archive/src/main/java/java/util/jar/ module
> > contributors on board? Could anyone clarify the reasons behind heavy
> > solution to copy manifest chunks into a separate hash table descried
> > at HARMONY-4569? Aren't entity hash table the only object which should
> > be populated?
> >
> > --
> > With best regards,
> > Alexei
> >
> > [1] http://issues.apache.org/jira/browse/HARMONY-4569
> >
>
>
>
> --
> With best regards,
> Alexei
>