[ 
https://issues.apache.org/jira/browse/SOLR-15559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386540#comment-17386540
 ] 

Gus Heck commented on SOLR-15559:
---------------------------------

*Default memory*
{code:java}
Benchmark                  Mode  Cnt       Score      Error  Units
MyBenchmark.testCharBuff  thrpt   25  346896.291 ± 6717.362  ops/s
MyBenchmark.testClassic   thrpt   25  204691.222 ± 2944.000  ops/s
{code}
speedup = ~2 microseconds, 40%

*Memory constrained to 8mb*
{code:java}
Benchmark                  Mode  Cnt       Score      Error  Units
MyBenchmark.testCharBuff  thrpt   25  187599.422 ± 17714.713  ops/s
MyBenchmark.testClassic   thrpt   25  127792.646 ±  8938.638  ops/s
{code}
speedup = 2.5 microseconds, 31%

*Memory constrained to 5mb*
{code:java}
Benchmark                  Mode  Cnt       Score      Error  Units
MyBenchmark.testCharBuff  thrpt   25  209509.435 ± 11178.546  ops/s
MyBenchmark.testClassic   thrpt   25  117720.233 ± 10968.465  ops/s
{code}
speedup = 3.7 microseconds, 43%

 

5mb was the lowes memory I could run the test under, I think there both tests 
are regularly GCing, and in the unconstrained memory which should be several 
GB, I suspect there was little GC. I did not verify this with a profiler 
however.  My conclusion s that this likely does some small good and no harm.

> Avoid object creation in splitSmart()
> -------------------------------------
>
>                 Key: SOLR-15559
>                 URL: https://issues.apache.org/jira/browse/SOLR-15559
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: main (9.0), 8.9
>            Reporter: Gus Heck
>            Assignee: Gus Heck
>            Priority: Minor
>         Attachments: MyBenchmark.java
>
>
> While reading code for other things I noticed a small inefficiency in the 
> splitSmart(String, String, boolean) method where it's creating new 
> StringBuilder objects unnecessarily inside a loop. For fun I fixed this and 
> JMH bench marked the fix to see what it was worth. The answer is about 30% 
> relative improvement, but only a couple microseconds absolute. Not exactly 
> exciting since I don't think there's anywhere that really loops hard on this, 
> but having it coded and tests passing and improvements measured, might as 
> well put it in.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to