Re: [compress] Some Compressor Benchmarks

[Stefan Bodewig]

On 2017-02-25, Stefan Bodewig wrote:

> On 2017-02-25, Stefan Bodewig wrote:

>> I'll write benchmarks for the Checksum algos next, it might be the
>> xxhash32 implementation being slower than the crc32-c we've got.

> It is, by a factor of two.

It was, by now xxhash32 is a tiny bit faster :-)

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Some Compressor Benchmarks

[Stefan Bodewig]

On 2017-02-25, Stefan Bodewig wrote:

> I'll write benchmarks for the Checksum algos next, it might be the
> xxhash32 implementation being slower than the crc32-c we've got.

It is, by a factor of two.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[compress] Some Compressor Benchmarks

[Stefan Bodewig]

Hi all

I've started to play with jmh[1] a bit, primarily as I wanted to tune
the LZ77 code a little before proposing the next release. Code is in my
github space[2]

While I was at it I thought it would be nice to compare the performance
of the compression formats we support:

  
https://github.com/bodewig/commons-compress-benchmarks/wiki/Comparison-of-Compression-Formats

As expected the performance of the zlib based native gzip/deflate
compressors/decompressors is superior to all others.  The performance of
the pure Java LZ77 I've implemented for snappy and lz4 doesn't look too
bad, but I'm surprised to see Snappy is so much faster than LZ4 (they
share most of the code). I'll write benchmarks for the Checksum algos
next, it might be the xxhash32 implementation being slower than the
crc32-c we've got.

By all means I'm not an expert in benchmarks, much less so in jmh, so if
I'm doing anything wrong, please tell me.

Stefan

[1] http://openjdk.java.net/projects/code-tools/jmh/
[2] https://github.com/bodewig/commons-compress-benchmarks/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Build failed in Jenkins: commons-cli #15

[Apache Jenkins Server]

See 

Changes:

[Robert Scholte] CLI-269: Introduce CommandLine.Builder

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on beam1 (beam) in workspace 

Updating https://svn.apache.org/repos/asf/commons/proper/cli/trunk at revision 
'2017-02-25T11:47:08.221 +'
U src/test/java/org/apache/commons/cli/CommandLineTest.java
U src/main/java/org/apache/commons/cli/CommandLine.java
At revision 1784367

Parsing POMs
Established TCP socket on 41574
Copied maven32-agent.jar
Copied maven32-interceptor.jar
maven3-interceptor-commons.jar already up to date
[commons-cli] $ /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g -Xms256m -cp 
/home/jenkins/jenkins-slave/maven32-agent.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.2.5/conf/logging
 jenkins.maven3.agent.Maven32Main /home/jenkins/tools/maven/apache-maven-3.2.5 
/home/jenkins/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven32-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 41574
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:254)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:143)
at jenkins.maven3.agent.Maven32Main.main(Maven32Main.java:74)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:365)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
at hudson.slaves.Channels.forProcess(Channels.java:115)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:294)
at hudson.maven.ProcessCache.get(ProcessCache.java:236)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:798)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1728)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:544)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Why have a HashSetvBitSetTest?

[Pascal Schumacher]

Hi Allon,

there is this issue: https://issues.apache.org/jira/browse/LANG-1110 and 
this pull request: https://github.com/apache/commons-lang/pull/182 which 
plan to convert the test to a JMH based benchmark.


I think the plan was to merge the pull request soon. If that does not 
happen, I'm +1 to ignoring the test.


Cheers,
Pascal

Am 25.02.2017 um 09:51 schrieb Allon Mureinik:

Hi all,

Building commons-lang locally made me notice HashSetvBitSetTest, which made
me wonder why we need it as a unit test.

I'm guessing it was originally used to support a design decision about
which data structure to use. But having done it, we now have  a relatively
slow test (on my machine - 0.582 seconds out of a total seconds it takes to
mvn test ~ 2.1%), which prints to stdout, and doesn't test any
functionality of the code provided in commons-lang.

Wouldn't it make more sense to @Ignore this test and just run it when a new
jvm/jdk is tested? or even remove it completely?


-Allon




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Why have a HashSetvBitSetTest?

[Allon Mureinik]

Hi all,

Building commons-lang locally made me notice HashSetvBitSetTest, which made
me wonder why we need it as a unit test.

I'm guessing it was originally used to support a design decision about
which data structure to use. But having done it, we now have  a relatively
slow test (on my machine - 0.582 seconds out of a total seconds it takes to
mvn test ~ 2.1%), which prints to stdout, and doesn't test any
functionality of the code provided in commons-lang.

Wouldn't it make more sense to @Ignore this test and just run it when a new
jvm/jdk is tested? or even remove it completely?


-Allon

[lang] Question with the StringEscapeUtils.(un)escapeEcmaScript

[Yasser Zamani]

Hi there,

I just wonder why `StringEscapeUtils.escapeEcmaScript` also includes 
`JavaUnicodeEscaper`? is it it's business really? the problem is when we 
use it to prevent script injection by user, it also replaces user 
input's unicodes with "\u"s which is not deducted with 
`escapeEcmaScript' term.

Another thing is, it replaces e.g. '<' with '' (html/xml escape) but 
replace unicode with '\u' rather than