Changes between Version 5 and Version 6 of SquirrelFishPerfIdeas


Ignore:
Timestamp:
Apr 20, 2008 8:22:19 PM (16 years ago)
Author:
mjs@apple.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SquirrelFishPerfIdeas

    v5 v6  
    2121'''Analysis of SunSpider tests that show little improvement'''
    2222
     23These tests don't show as much improvement from SquirrelFish as expected (though in some cases they are as much as 7% improved).
     24
    23253d-morph: Suffering from missing cross-scope access optimization and DontDelete global optimization (9.4% deep time in resolve()). Probably suffering from lack of static type inference (lots of time in jsNumberCell, JSImmediate, NumberImp::toNumber, etc.
    2426
    25 access-nbody: Major factor seems to be lack of type specialization (lots of time in number-related stuff).
     27access-nbody: Major factor seems to be lack of type specialization (lots of time in number-related stuff). A huge proportion of time is flat time in privatExecute. Some hit (1%?) from lack of multiscope.
    2628
    27 date-format-tofte: Lots of time spent in parsing and code generation for eval. Can codegen itself be optimized? Also lots of time in makeFunction(), a big chunk of this is making the empty prototype for the function object, as well as setting the special properties (prototype, constructor, length), perhaps those coudl be handled in a smarter way. Also function call overhead for FuncDeclNode::makeFunction itself. Perhaps it should be inlined. Also it is suspicious that call overhead for makeFunction would be a bottleneck, is it getting called more often than it should?
     29date-format-tofte: Lots of time spent in parsing and code generation for eval. Can codegen itself be optimized? Also lots of time in makeFunction(), a big chunk of this is making the empty prototype for the function object, as well as setting the special properties (prototype, constructor, length), perhaps those coudl be handled in a smarter way. Also function call overhead for FuncDeclNode::makeFunction itself. Perhaps it should be inlined. Also it is suspicious that call overhead for makeFunction would be a bottleneck, is it getting called more often than it should? Also taking some hit from lack of multiscope.
    2830
    29 date-format-xparb:
     31date-format-xparb: taking a 5% hit from lack of multiscope optimization. Also spending an awful lot of time in string appends.
    3032
     33math-partial-sums: Lots of time in resolve/resolveBase. (Lack of global opt + possible bug in test). Hit from lack of type specialization. This is taking a fair hit from the VM_EXCEPTION_CHECK call in put_prop_id. We should move this onto our new zero cost exception check scheme (pass vPC in and out etc).
     34
     35regexp-dna: practically all time in this test is in the regexp engine. Will need regexp engine hacking to improve.
     36
     37string-base64: 5% of time spent in slow global lookup. Other improvement opportunities: some form of immediate for one-char strings; void allocating a fresh StringInstance wrapper all the time.
     38
     39string-fasta:
     40
     41string-tagcloud:
     42
     43string-unpack-code:
     44
     45string-validate-input: