#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 -----------------------------+---------------------------- Comment (by SeanCollins): Replying to [comment:64 bonefish]: > jua, thanks for the new patch. Regarding the performance tests, not knowing what they test exactly I cannot say how meaningful the results are. From a quick look at [http://reference.kfupm.edu.sa/content/s/p/the_splash_2_programs__characterization__57664.pdf this paper] the focus is definitely not on testing locking primitives. Testing userland locking primitives wouldn't be that interesting anyway, since the syscall overhead outweighs lengthened code paths in the kernel by far. > > A helpful performance test would cause a lot of locking in the kernel. Instead of devising a test specifically for that purpose, I'd first try something simple like building a Haiku image with multiple jobs on an SMP machine (ideally 8 jobs on 8 logical CPUs). From my experience this causes quite a bit of lock contention in the VFS and VM subsystems already. It's also a real world test with practical relevance. ''I got a system time of 15min and a kernel time of 50min to build Haiku. The disparity is much smaller on Linux system. I just wouldn't expect such a drastic difference in compile time. Maybe this is all pointing to the same symptom.'' as noted above, this time has not changed in any significant way for me, so the patch does not appear to impact performance in a statistically meaningful way. -- Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:68> Haiku <http://dev.haiku-os.org> Haiku - the operating system.