Changeset 237054 in webkit for trunk/Source/JavaScriptCore/ChangeLog
- Timestamp:
- Oct 11, 2018, 4:43:58 PM (7 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/JavaScriptCore/ChangeLog
r237051 r237054 1 2018-10-08 Yusuke Suzuki <[email protected]> 2 3 [JSC] JSC should have "parseFunction" to optimize Function constructor 4 https://bugs.webkit.org/show_bug.cgi?id=190340 5 6 Reviewed by Mark Lam. 7 8 The current Function constructor is suboptimal. We parse the piece of the same code three times to meet 9 the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function. 10 And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation 11 is really costly and ideally we should meet the above requirement by the one time parsing. 12 13 To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function 14 takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser. 15 For example, if we run the code, 16 17 Function('/*', '*/){') 18 19 According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter 20 string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing 21 that, in our implementation, we first create the entire string. 22 23 function anonymous(/*) { 24 */){ 25 } 26 27 And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case, 28 the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token 29 offset of the parameters is the given end position. This check allows us to raise the error correctly to the 30 above example while we parse the entire function only once. And we do not need to create two strings too. 31 32 This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is 33 significantly sped up (28.2%). 34 35 Before: 36 uglify-js: 2.94 runs/s 37 After: 38 uglify-js: 3.77 runs/s 39 40 * bytecode/UnlinkedFunctionExecutable.cpp: 41 (JSC::UnlinkedFunctionExecutable::fromGlobalCode): 42 * bytecode/UnlinkedFunctionExecutable.h: 43 * parser/Parser.cpp: 44 (JSC::Parser<LexerType>::parseInner): 45 (JSC::Parser<LexerType>::parseSingleFunction): 46 (JSC::Parser<LexerType>::parseFunctionInfo): 47 (JSC::Parser<LexerType>::parseFunctionDeclaration): 48 (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): 49 (JSC::Parser<LexerType>::parseClass): 50 (JSC::Parser<LexerType>::parsePropertyMethod): 51 (JSC::Parser<LexerType>::parseGetterSetter): 52 (JSC::Parser<LexerType>::parseFunctionExpression): 53 (JSC::Parser<LexerType>::parseAsyncFunctionExpression): 54 (JSC::Parser<LexerType>::parseArrowFunctionExpression): 55 * parser/Parser.h: 56 (JSC::Parser<LexerType>::parse): 57 (JSC::parse): 58 (JSC::parseFunctionForFunctionConstructor): 59 * parser/ParserModes.h: 60 * parser/ParserTokens.h: 61 (JSC::JSTextPosition::JSTextPosition): 62 (JSC::JSTokenLocation::JSTokenLocation): Deleted. 63 * parser/SourceCodeKey.h: 64 (JSC::SourceCodeKey::SourceCodeKey): 65 (JSC::SourceCodeKey::operator== const): 66 * runtime/CodeCache.cpp: 67 (JSC::CodeCache::getUnlinkedGlobalCodeBlock): 68 (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): 69 * runtime/CodeCache.h: 70 * runtime/FunctionConstructor.cpp: 71 (JSC::constructFunctionSkippingEvalEnabledCheck): 72 * runtime/FunctionExecutable.cpp: 73 (JSC::FunctionExecutable::fromGlobalCode): 74 * runtime/FunctionExecutable.h: 75 1 76 2018-10-11 Ross Kirsling <[email protected]> 2 77
Note:
See TracChangeset
for help on using the changeset viewer.