ASF GitHub Bot commented on NIFI-2851:

Github user olegz commented on a diff in the pull request:

    --- Diff: 
    @@ -798,6 +798,7 @@ public void testWithSplitThatStartsWithNewLine() {
    +    @Ignore // temporary, fixing it
    --- End diff --
    No, didn't want to hold the PR as this is kind of an edge case which I hope 
to address after thinking about it a bit. 
    Basically the assertion fails here 
```splits.get(1).assertContentEquals("");``` since it now comes it as new line. 
But I also wonder why is this a split to begin with with no data?
    So, i wanted to look some more as well as see if it is actually a bug that 
needs to be fixed, but didn't want to hold the PR since regardless this is an 
edge case.

> Improve performance of SplitText
> --------------------------------
>                 Key: NIFI-2851
>                 URL: https://issues.apache.org/jira/browse/NIFI-2851
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Core Framework
>            Reporter: Mark Payne
>            Assignee: Oleg Zhurakousky
>             Fix For: 1.1.0
> SplitText is fairly CPU-intensive and quite slow. A simple flow that splits a 
> 1.4 million line text file into 5k line chunks and then splits those 5k line 
> chunks into 1 line chunks is only capable of pushing through about 10k lines 
> per second. This equates to about 10 MB/sec. JVisualVM shows that the 
> majority of the time is spent in the locateSplitPoint() method. Isolating 
> this code and inspecting how it works, and using some micro-benchmarking, it 
> appears that if we refactor the calls to InputStream.read() to instead read 
> into a byte array, we can improve performance.

This message was sent by Atlassian JIRA

Reply via email to