[
https://issues.apache.org/jira/browse/RAT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17802236#comment-17802236
]
Romain Manni-Bucau commented on RAT-340:
----------------------------------------
Is the slowness identified? from experience mulithreading something related to
disk accesses - even on SSD - will not save much time so there should be some
sort of expensive computation which can be fixed by itself if you detect a
regression in terms of perf?
The diff is not obvious in terms of what 0.17 is (no code change compared to
0.16 so will not be slower):
https://github.com/apache/creadur-rat/compare/apache-rat-project-0.16...master
> Make processing multi-threaded.
> -------------------------------
>
> Key: RAT-340
> URL: https://issues.apache.org/jira/browse/RAT-340
> Project: Apache Rat
> Issue Type: New Feature
> Affects Versions: 0.17
> Reporter: Claude Warren
> Priority: Major
>
> This should be an epic of some sort.
> I believe that 0.17 is much slower than 0.16
> I also believe that the process could benefit from making the process
> multi-threaded.
> To do this:
> * The IHeaderMatcher implementations will need to be made thread safe.
> * IReport will have to queue reports for processing and will need to detect
> when the queue is full and wait for space.
> * The RatReport/IReport interface will have to be examined to ensure that
> multiple threads can report completed reports and have them correctly
> reflected in the resulting XML while still performing the modifications that
> some IReport implementations perform.
> * Standard Java thread pooling will need to be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
