[
https://issues.apache.org/jira/browse/NIFI-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15129615#comment-15129615
]
ASF GitHub Bot commented on NIFI-1460:
--------------------------------------
Github user PuspenduBanerjee commented on the pull request:
https://github.com/apache/nifi/pull/202#issuecomment-178958929
@trkurc :+1: That's a good catch. Yes Long.toString(long) is faster but
the difference is only about ~60 milliSeconds for 10^20 iteration because:
```java
/**
* Returns a {@code String} object representing this
* {@code Long}'s value. The value is converted to signed
* decimal representation and returned as a string, exactly as if
* the {@code long} value were given as an argument to the
* {@link java.lang.Long#toString(long)} method.
*
* @return a string representation of the value of this object in
* base 10.
*/
public String toString() {
return toString(value);
}
```
But, do you think that should be accounted against the manageability of the
method in context of the provided test scenario?
And, please try the following code, try to run it & you will something
noticeable:
```java
public static void main(String args[]){
for (int i = 0; i < 100; i++) {
main1();
}
}
public static void main1(){
long iter = 1<<20;
AtomicLong ai = new AtomicLong(0);
long now = System.currentTimeMillis();
for(int i=0; i < iter; i++) {
Long x = ai.getAndIncrement();
String x2 = x.toString();
}
System.out.printf("1 ===== %d elapsed\n",
(System.currentTimeMillis() - now ));
now = System.currentTimeMillis();
for(int i=0; i < iter; i++) {
String x2 = Long.toString(ai.getAndIncrement());
}
System.out.printf("2 ===== %d elapsed\n",
(System.currentTimeMillis() - now ));
System.out.println("=============================DONE========================");
}
```
> Test Performance improvement. Test Timeout Mitigation.
> ------------------------------------------------------
>
> Key: NIFI-1460
> URL: https://issues.apache.org/jira/browse/NIFI-1460
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Tools and Build
> Affects Versions: 0.4.1
> Environment: linux, unix with true random number generator.
> Reporter: Puspendu Banerjee
> Priority: Minor
> Labels: performance
> Fix For: 0.5.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Existing test case
> nifi-framework-core/src/test/java/org/apache/nifi/controller/TestStandardFlowFileQueue.java
> uses a huge number of call to UUID.randomUUID() which is very slow in linux
> , unix environment if there is not much activity [ like mouse move etc.] .In
> addition to that UUID.randomUUID() depends on /dev/(u)random to get a random
> number, such system call costs IO and /dev/random is bandwidth/rate limited
> which again slows down overall performance.
> Workaround is rngd daemon(ref: http://linux.die.net/man/8/rngd)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
