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

Performance regression in 0.84.3 - overzealous debug logging? #119

Closed
jpd236 opened this issue Feb 5, 2023 · 4 comments
Closed

Performance regression in 0.84.3 - overzealous debug logging? #119

jpd236 opened this issue Feb 5, 2023 · 4 comments
Labels
indev The issue is fixed/implemented in the dev branch

Comments

@jpd236
Copy link
Contributor

jpd236 commented Feb 5, 2023

There is noticeably slower performance in my app, a Chrome extension which is serializing a file to XML (using Kotlin/JS), when upgrading from 0.84.2 to 0.84.3.

While I haven't traced it too finely, there is a very observable difference - in the Chrome console, there is a ton of console logging that begins, "DEBUG - attribute - ..." - like thousands of lines (one per attribute?) over what is at most a 1-2 second operation. It seems plausible that this is causing a bottleneck.

Perhaps this logging was unintentionally committed as part of 25bd973 and should just be removed or put behind some other if (DEBUG) check?

pdvrieze added a commit that referenced this issue Feb 6, 2023
@pdvrieze pdvrieze added the indev The issue is fixed/implemented in the dev branch label Feb 6, 2023
@pdvrieze
Copy link
Owner

pdvrieze commented Feb 6, 2023

You're right. They shouldn't have been there. Btw. for performance you may want to try using the platform independent writer rather than the default DOM based writer (Either create KtXmlWriter directly or use XmlStreaming.newGenericWriter - it does the same, but XmlStreaming is the platform independent entry point). DOM is known to be slow in cases, and in general it could be faster to write Xml directly to a string rather than indirectly through DOM (dependent upon the optimization applied).

There should be an automatic snapshot released soon.

@jpd236
Copy link
Contributor Author

jpd236 commented Feb 7, 2023

Thanks!

The XML files we're dealing with here are typically ~tens of KBs... I'd hope that's small enough that any performance difference between the two wouldn't be too significant in the grand scheme of things. I don't see any significant differences from some quick testing. (It also results in very slight output differences vs. the default writer, due to use of single quotes in the doctype and spaces before the end of self-closing tags, but that is probably reconcilable, and if not, I could fix my test files).

@pdvrieze
Copy link
Owner

pdvrieze commented Feb 7, 2023

@jpd236 For your testing you may want to look at the test code in the library. There is actually an XML comparison tool in there that tries to compare according to XML rules (rather than string comparison). It would also make your tests more robust against different browsers as there is no set formatting that must be used (like single vs double quotes).

@pdvrieze
Copy link
Owner

Now released in 0.85.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
indev The issue is fixed/implemented in the dev branch
Projects
None yet
Development

No branches or pull requests

2 participants