-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
fix(dash): Fix performance regression #4064
Conversation
87f24e7
to
dabaf47
Compare
dabaf47
to
c356169
Compare
@avelad can I suggest another improvement in The following is MUCH faster (and causes less GC) than /**
* Finds child XML elements.
* @param {!Node} elem The parent XML element.
* @param {string} name The child XML element's tag name.
* @return {!Array.<!Element>} The child XML elements.
*/
static findChildren(elem, name) {
const found = [];
for (const child of elem.childNodes) {
if (child instanceof Element && child.tagName == name) {
found.push(child);
}
}
return found;
}
/**
* Finds namespace-qualified child XML elements.
* @param {!Node} elem The parent XML element.
* @param {string} ns The child XML element's namespace URI.
* @param {string} name The child XML element's local name.
* @return {!Array.<!Element>} The child XML elements.
*/
static findChildrenNS(elem, ns, name) {
const found = [];
for (const child of elem.childNodes) {
if (child instanceof Element && child.localName == name &&
child.namespaceURI == ns) {
found.push(child);
}
}
return found;
} |
c356169
to
ee5e3ea
Compare
Still too slow though - I'm investigating. |
@philippe-elsass-deltatre do you have any update? |
I'm profiling Shaka 2.5 VS 3 (debug versions), and Shaka 2.5 is still literally twice as fast. Not sure why. |
@@ -225,8 +225,7 @@ shaka.dash.MpdUtils = class { | |||
timeline[timeline.length - 1].end = startTime / timescale; | |||
} | |||
|
|||
for (const _ of shaka.util.Iterables.range(repeat + 1)) { | |||
shaka.util.Functional.ignored(_); | |||
for (let j = 0; j <= repeat; ++j) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For historical context, we used to have frequent issues with mistakes in code like this. It is easy to mix up i
and j
for example, and easy to overlook in code review. So Iterables
was a way to avoid the need for those.
Clearly the performance penalty is too great, though. We should figure out what other things transpile into poorly-performing ES5 and eliminate them. We could even write a test that would check the binary for poorly-performing polyfills, to catch regressions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From Monday I will continue working on other improvements, but I will create other PRs.
@joeyparrish can you cherry-pick it to 3.3? Thanks! |
See: #4062 (comment)