mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-02-03 12:35:58 +00:00
Patches from Igor:
Note form omj/Parser.java: * OPT source info collection is a potential performance bottleneck; * Source wraps a java.lang.StringBuffer, which is synchronized. It * might be faster to implement Source with its own char buffer and * toString method. It is indeed a bottleneck under JDK 1.1. When I replaced StringBuffer by a char array (see the attached patch), execution time of Context.compileReader decreased by 15%: to test I combined a few test cases to get a 3MB JS source and then measured time to process it by Context.compileReader in the interpreter mode. Under JDK 1.3 the difference is less then 1%, but still using the explicit string buffer saves memory. When converting StringBuffer to String Sun JDK shares the internal char array in StringBuffer with new String, but in the Parser case typically the capacity of this buffer is bigger then the actual string length, so this unused space in source strings is wasted in the interpreter mode that keeps these strings in InterpreterData. Regards, Igor ======== I implemented that member expression as function name syntactic sugar to support scripts using this MS extension. This is only available when Context.hasFeature(Context.FEATURE_MEMBER_EXPR_AS_FUNCTION_NAME) returns true to allow the deviation from the standard only when required. The patch effectively transforms 'function <memberExpr>(...)...' to '<memberExpr> = function(...)...' when <memberExpr> is not simple identifier. I am not sure that MS implementation does exactly this but hopefully it is sufficiently general to cover MS cases. (The patch assumes that source_change.patch is already applied) Regards, Igor
This commit is contained in:
parent
367774a772
commit
3d2e81a014
File diff suppressed because it is too large
Load Diff
Loading…
x
Reference in New Issue
Block a user