#8007: [app_server] fully unresponsive when resizing window of big textfile -----------------------------+---------------------------- Reporter: ttcoder | Owner: axeld Type: bug | Status: new Priority: normal | Milestone: R1 Component: System/Kernel | Version: R1/Development Resolution: | Keywords: Blocked By: | Blocking: 7882, 8136 Has a Patch: 0 | Platform: All -----------------------------+---------------------------- Changes (by jua): * patch: 1 => 0 Comment: Ok, here's are the results for building haiku images. * The machine has 2 cores, I made test builds with and without "-j2" * The first builds I made were accidentally with KDEBUG enabled, so I have results with and without that too... {{{ (1) KDEBUG, jam @anyboot-image Original | Patched --------------------+------------------- real 95m5.039s | real 95m47.065s user 68m27.017s | user 68m14.016s sys 19m30.045s | sys 19m58.322s (2) KDEBUG, jam -j2 @anyboot-image Original | Patched --------------------+------------------- real 52m47.789s | real 53m3.095s user 69m24.631s | user 69m9.291s sys 22m11.243s | sys 22m36.019s (3) jam @anyboot-image Original | Patched --------------------+------------------- real 88m13.260s | real 88m10.470s user 67m59.852s | user 68m0.633s sys 13m5.890s | sys 14m7.008s (4) jam -j2 @anyboot-image Original | Patched --------------------+------------------- real 47m46.024s | real 48m51.425s user 68m50.666s | user 68m55.215s sys 13m44.617s | sys 15m33.951s }}} Most relevant are cases (3) and (4), the sys time increases ~8% in (3) and ~10% in (4), but for the real time it looks much less bad. Note that I only ran these builds one time each, so there is certainly an error margin, especially because the build process downloads files... I didn't set up a caching proxy or anything, so internet download speed fluctuation is in there too. That probably decreases the significance of the real time values. -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:66> Haiku <http://dev.haiku-os.org> Haiku - the operating system.