Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logger/string formatting slows down some calculations #789

Open
biocryst opened this issue Aug 7, 2018 · 4 comments
Open

Logger/string formatting slows down some calculations #789

biocryst opened this issue Aug 7, 2018 · 4 comments
Labels

Comments

@biocryst
Copy link
Member

@biocryst biocryst commented Aug 7, 2018

Calculating secondary structure of 4hhb 10000 times takes 589 seconds on my machine. If the following two lines are commented out, it takes 34 seconds:

logger.debug(" cccc: " + one.getResidueNumber() +
" " + one.getPDBName() + " " +two.getResidueNumber()+
" " + two.getPDBName() + String.format(" O ("+
O.getPDBserial()+")..N ("+ N.getPDBserial()+
"):%4.1f | ho:%4.1f - hc:%4.1f + nc:%4.1f - no:%4.1f ",
dno,dho,dhc,dnc,dno));

logger.debug(String.format(" N (%d) O(%d): %4.1f : %4.2f ",
N.getPDBserial(),O.getPDBserial(), (float) dno, energy));

The problem is likely to be in the String.format method. Using SLF4J parameterized messages instead ("{}") is much faster, but does not support float formatting to number of decimal places (see https://stackoverflow.com/questions/22720865/formatting-floating-point-numbers-in-slf4j, thanks @josemduarte ).

My suggestion is to go through the logging messages which use string formatting and, if feasible, change them to parameterized messages.

The performance is noticeably affected only if the logging statements are somewhere deep within a loop.

@biocryst biocryst added the enhancement label Aug 7, 2018
@josemduarte
Copy link
Contributor

@josemduarte josemduarte commented Aug 7, 2018

Good catch! Indeed this shows how careful use of the loggers is very important.

So reminder for everyone: please always use string substitution:

logger.debug("The value of var is {}", var);

in favor of concatenation:

logger.debug("The value of var is " + var);

Reference: https://www.slf4j.org/faq.html#logging_performance

@sbliven
Copy link
Member

@sbliven sbliven commented Dec 13, 2018

Should we search systematically for string concatenations or String.format calls in logging statements?

@lee-mcfaul
Copy link
Contributor

@lee-mcfaul lee-mcfaul commented Mar 1, 2019

Sonarqube is a pretty good tool for finding such things as well as a plethora of other coding bugs, smells and other faux-pas. It's a little depressing running it on a codebase for the first time, but overall it's a pretty good tool to keep code clean and use best practices.

It could be set up similar to the Travis build where code bellow a certain quality is blocked from merging.

https://www.sonarqube.org/

@josemduarte
Copy link
Contributor

@josemduarte josemduarte commented Mar 1, 2019

Yes, Sonarqube is indeed a great tool. We are actually trying it right now for other projects. I'm going to give SonarCloud a try in BioJava as soon as I can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.