Performance regression introduced with plexus-io 3.4.0

[e-hubert]

We faced a notable performance regression of maven builds when updating the maven-jar-plugin which is very likely related to the changes in #79.
What we know for sure is that downgrading the plexus-io dependency from 3.4.0 to 3.3.1 removes the issue.

<dependencies>
    <dependency>
        <groupId>org.apache.maven</groupId>
        <artifactId>maven-archiver</artifactId>
        <version>3.6.0</version>
        <exclusions>
            <exclusion>
                <groupId>org.codehaus.plexus</groupId>
                <artifactId>plexus-io</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <!-- Downgrade plexus-io to 3.3.1 to avoid performance regression during archive build -->
    <dependency>
        <groupId>org.codehaus.plexus</groupId>
        <artifactId>plexus-io</artifactId>
        <version>3.3.1</version>
    </dependency>
</dependencies>

This is a captured stacktrace of the slowed down code path:
at sun.nio.fs.UnixNativeDispatcher.getgrgid(java.base@17.0.7/Native Method)
at sun.nio.fs.UnixUserPrincipals.fromGid(java.base@17.0.7/UnixUserPrincipals.java:125)
at sun.nio.fs.UnixFileAttributes.group(java.base@17.0.7/UnixFileAttributes.java:212)
- locked <0x00000006cbf60f10> (a sun.nio.fs.UnixFileAttributes)
at sun.nio.fs.UnixFileAttributeViews$Posix.addRequestedPosixAttributes(java.base@17.0.7/UnixFileAttributeViews.java:237)
at sun.nio.fs.UnixFileAttributeViews$Unix.readAttributes(java.base@17.0.7/UnixFileAttributeViews.java:385)
at sun.nio.fs.AbstractFileSystemProvider.readAttributes(java.base@17.0.7/AbstractFileSystemProvider.java:94)
at java.nio.file.Files.readAttributes(java.base@17.0.7/Files.java:2084)
at org.codehaus.plexus.components.io.attributes.FileAttributes.(FileAttributes.java:110)
at org.codehaus.plexus.components.io.attributes.FileAttributes.(FileAttributes.java:88)
at org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResources(PlexusIoFileResourceCollection.java:163)
at org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:262)
at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:564)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:224)
at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:202)
at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:1028)

We suspect a relation to #79 although we did not look into the details.
Just looking at the stack the cause is likely related to more frequent native FS related calls triggered by execution of java.nio.file.Files.readAttributes from PlexusIoFileResourceCollection.

PS: The used JDK version is not relevant - it at least occurs for both latest OpenJDK 11 and 17 (only tested on Linux, but I'd expect the impact on Windows to be even larger). For a very large project this more than doubled the total build time on some systems - the minimal observed overhead was about 20%, which is still considerable.

[gnodet]

See #79 (comment)

[cpovirk]

In our case, we found a workaround: The problem appears to happen only with large/remote definitions of Unix groups, so we can avoid it by assigning our files to a group that is part of the local /etc/group file.

[cpovirk]

Oh, and one cool thing I discovered along the way is that ls has a cache of its own for group names: In format_group, it calls getgroup, which implements a cache. Apparently it's been that way for at least 32 years :)

[gnodet]

@cpovirk could you please check if #135 fixes the problem for you ?

[gnodet]

@cpovirk could you please check if #135 fixes the problem for you ?

and @e-hubert too ...

[marek-neumann-opti]

Tested the fix from #135 and I can confirm this worked.

[cpovirk]

Confirmed as well. Thanks very much!