[
https://issues.apache.org/jira/browse/RAT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804619#comment-17804619
]
Romain Manni-Bucau commented on RAT-340:
----------------------------------------
I see then my 2cts would be that most of the "by line processing" can be
boosted by having a prematcher on the file (indexOf) - true for most matchers -
and not just use regex per lines. This is kind of suggested in the comments but
think it should be more global and would boost even v0.15 version.
Now my main concern is that if you use it in a parallel build the
multithreading will slow down the execution in general so is not a good option.
Is the fact to reconsider this "make it multithreaded" to something like
"optimize the matching logic [in a single thread]"?
> 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)
