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

Improved "include" fix performance: optimized normalizePath method #3063

Merged
merged 3 commits into from Jul 28, 2022

Conversation

lzxgyh
Copy link
Contributor

@lzxgyh lzxgyh commented Jul 14, 2022

Impact

  • Bug fix (non-breaking change which fixes expected existing functionality)
  • Enhancement/New feature (adds functionality without impacting existing logic)
  • Breaking change (fix or feature that would cause existing functionality to change)

Description

Replaces on-the-fly regular expression usage with pre-compiled versions.

Fixes #2221
Fixes #1856

Things to be aware of

  • Nothing

Things to worry about

  • Nothing

Additional Context

Add any other context about the problem here.

@kataggart kataggart added this to To Do in Conditioning++ via automation Jul 14, 2022
@nvoxland
Copy link
Contributor

Thanks @lzxgyh!
I updated the description to remove the boilerplate template with what was done.

I worry about the creation of the matcher static variables, though. If this gets used in a multithreaded way, I think those will cause problems. If you just create the matchers as local variables instead of resetting the static variables does it loose a lot of the performance gains? The original "compile" call should be what makes the most difference, right?

@lzxgyh lzxgyh closed this Jul 15, 2022
Conditioning++ automation moved this from To Do to Done Jul 15, 2022
@lzxgyh lzxgyh reopened this Jul 15, 2022
Conditioning++ automation moved this from Done to To Do Jul 15, 2022
@lzxgyh
Copy link
Contributor Author

lzxgyh commented Jul 15, 2022

Thanks @lzxgyh! I updated the description to remove the boilerplate template with what was done.

I worry about the creation of the matcher static variables, though. If this gets used in a multithreaded way, I think those will cause problems. If you just create the matchers as local variables instead of resetting the static variables does it loose a lot of the performance gains? The original "compile" call should be what makes the most difference, right?

Hi nvoxland

I think you are right, in the past, I always thought that liquibase was a single-threaded tool

@nvoxland
Copy link
Contributor

Are you able to fix that up quick, @lzxgyh?

@lzxgyh
Copy link
Contributor Author

lzxgyh commented Jul 16, 2022

Sure, I pushed a new commit to remove the matcher static variables , Please review @nvoxland

@nvoxland nvoxland added the SafeToBuild Indicates that a particular PR contains changes which are safe to build using GitHub actions label Jul 19, 2022
@github-actions
Copy link

github-actions bot commented Jul 19, 2022

Unit Test Results

  4 608 files  ±0    4 608 suites  ±0   39m 57s ⏱️ +19s
  4 589 tests ±0    4 371 ✔️  - 4     218 💤 +4  0 ±0 
54 240 runs  ±0  49 228 ✔️  - 4  5 012 💤 +4  0 ±0 

Results for commit 9194272. ± Comparison against base commit 1143689.

♻️ This comment has been updated with latest results.

@nvoxland nvoxland added SafeToBuild Indicates that a particular PR contains changes which are safe to build using GitHub actions and removed SafeToBuild Indicates that a particular PR contains changes which are safe to build using GitHub actions labels Jul 20, 2022
Copy link
Contributor

@nvoxland nvoxland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review and test results:

Things to be aware of:

  • Just moves implementation of where the regular expressions are managed from one spot to another, no functionality change
  • I did not re-test the performance improvements, but I can see from the performance dumps that this what a large problem in the code and the PR will fix it as the contributor says it does

Things to worry about:

  • Nothing

.replaceFirst("^\\.?/", "")
;

String noClassPathReplaced = NON_CLASSPATH_PATTERN.matcher(filePath).replaceFirst("");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @lzxgyh - This is a nice improvement to code readability!

Copy link
Contributor

@XDelphiGrl XDelphiGrl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Fix improves performance of normalizePath.
  • Fix improves readability of REGEX matching in DatabaseChangelog.java
  • No additional testing necessary.

APPROVED

Passing Functional Tests
Passing Test Harness Execution

@nvoxland nvoxland changed the title fix performance issue: normalizePath super slow? #2221 and issue: Optimize updates #1856 Improved "include" fix performance: optimized normalizePath method Jul 27, 2022
@nvoxland nvoxland merged commit a19df45 into liquibase:master Jul 28, 2022
Conditioning++ automation moved this from To Do to Done Jul 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
autocandidate SafeToBuild Indicates that a particular PR contains changes which are safe to build using GitHub actions sprint2022-30 TypeEnhancement
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

normalizePath super slow? Optimize updates
5 participants