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

Bad performance of textTagEndBlock4 in SwiftParser #5

Closed
ynleborg opened this issue May 23, 2017 · 3 comments
Closed

Bad performance of textTagEndBlock4 in SwiftParser #5

ynleborg opened this issue May 23, 2017 · 3 comments
Assignees

Comments

@ynleborg
Copy link

Since version SRU2016-7.8.5 there is a performance problem in the implementation of textTagEndBlock4 in SwiftParser. Processing increased from 3 seconds to 3 minutes for 14MB file. Profiling tools show, that most time is spent in substring method. We internally reverted implementation to SRU2015-7.7 and it fixed issue.

@zubri zubri self-assigned this May 23, 2017
@zubri
Copy link
Member

zubri commented May 23, 2017

Hi,

Thanks for the feedback.
We see no significant changes in the usage of substring calls in that method, neither in the whole parser.

Can you provide more details on how you are reading and parsing the 14MB file? Are you using the RJEReader?

@ynleborg
Copy link
Author

ynleborg commented May 26, 2017

I have prepared test that reproduces the bug: #6

On my computer shouldParseLargeFile runs 12 seconds on SRU2016-7.8.5 and 0,187s on SRU2015-7.7.
The number of processed records is the some in both cases: 30971.

@zubri zubri added this to the SRU2017 - Oct 2017 milestone May 30, 2017
@zubri
Copy link
Member

zubri commented May 30, 2017

This has been fixed to achieve previous performance. I've removed the substring call and refactored the tag start detection. It will be included in the upcoming SRU2017 release in October.

However, notice the large statement that you are using to produce the issue is not valid. And input MT940 can have at most 2K characters.

Also, the parser from 2015 7.7 you are using has a bug. It does not accept ':' as starting content in the second line of a field.

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

No branches or pull requests

2 participants