Analysis
Overview
The goal of this task is to improve the performance of the Sophie2 platform before the weekly at 2009-05-19.
Task requirements
Since time is not enough for great optimizations which require good design and much refactoring but instead locate small inefficient chunks of code and optimize them.
Such cases might include:
- modification of the launch settings of Author, Reader and Server
- memoization of often performed queries
- complexity optimizations of often executed code such as:
- hashing instead of iterating
- precomputing some results if possible
- etc...
- usage of more efficient data structures at certain classes if possible and not much time needed to refactor
Also some logging logic should be included which measures startup time so optimizations are with visible effect.
Task result
- visible performance optimization
- code for startup time measurement
- explanations of the optimizations in the wiki
Implementation idea
- tweak profiler settings for the launch configurations
- refactor main() method of FakeAuthorMain to measure time
- use a profiler to locate non-efficient chunks of code and optimize them
Related
How to demo
- demo performance optimization
Design
After playing with the vm arguments and launch configurations I figured out that using the HPROF profiler of the JVM may be omitted to improve development process.
In the author.FakeAuthorMain.launch conf file there a -agentlib:hprof=cpu=samples,interval=5,depth=30 argument passed to the JVM. This means that a profiler thread runs each 5 milliseconds, gathers information from the running Sophie process, and then sleeps again. This is useful when developing something for Sophie with the intent to use this performance log for optimizations.
In most cases this isn't the case so using the profiler is pointless. Turning it off leads to 20-30% startup time reduction which is significant, so I'll remove this from the author.FakeAuthorMain.launch (and reader.FakeReaderMain.launch respectively). For convenience, I'll create author.FakeAuthorMain-Debug.launch (and reader.FakeReaderMain-Debug.launch respectively), which have this option turned on. In the future more similar differences might occur.
I'll add simple execution time code in the FakeAuthorMain.main() method and log it.
Implementation
Soo..
- I modified the launch configurations and turned off hprof as described in the design section.
- I updated FakeAuthorMain.main() as described above.
- I tried using several profilers, after all for now me and Milo decided to try writing a simple profiler ourselves.
- I tried several quick low-level ProLib candidates for optimization which didn't actually help too much so I don't include them in the implementation.
- tried providing a swallow mode for the ProLib Registry. That is if swallow mode is on, no reads would get registered (which differs from the NoReadTrack-like behavior where no read are expected to be registered and an exception is thrown if a read tries to get registered). Didn't make a big difference, as expected.
- tried messing with filtering logic in the ProLib Registry.endReadTrack() method but also as expected it didn't help much.
- tried to move the filtering logic from outside endReadTrack() to inside TrackData guess what? As expected, it didn't help much also.
- tried messing with the listener attaching/detaching logic in AutoTracker.doUpdate(), and... it didn't help (:
- I spotted lots of potential pieces of code which could possibly be optimized though this requires more time and analyzing and will be done in the next revision of this task.
- as mentioned, I tried several of them with not much luck.
- others need more thinking and useful profiler, so I'll try them in the next revision.
Changeset: [2632], merged to trunk in [2769].
Testing
Not much to test in this task. Running the two different launch configurations shows the performance difference.
Comments
(Write comments for this or later revisions here.)
