Instead of unconditionally calling _DeriveLabel() and Invalidate()
every time (both expensive operations), use a bool to track whether
we've already invalidated, and derive the label in Draw() if it
was set.
Significantly decreases the invalidations done on full-list rebuilds.
* _UpdateThumbFrame() calls Invalidate() already, don't call it again
in SetRange unnecessarily.
* If the new and old thumb frames are the same, skip invalidation.
Saves a lot of Invalidate() calls in HaikuDepot on building the
"all packages" list especially.
* package->Name() is always lowercase, don't bother using lowercase
operations on it.
* Use IFindFirst rather than transforming the string; this uses
strcasestr internally which operates per-character.
Loosely based on a patch by oco in #19421.
when a non-null value is found, up to PTHREAD_DESTRUCTOR_ITERATIONS (4).
* fixes LLVM unit test SanitizerCommon.PthreadDestructorIterations.
Change-Id: I1f9f4d3e8723261326e6e22b0f0d23907dccb59f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8979
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
This case happens now and again, including a few dozen times in the
bootloader, hundreds of times on boot, and thousands of times
when running "git status" on larger repositories.
It reduces block_cache contention in "git status buildtools" specifically
from ~10m1s wait time to ~9m13s, and overall time from ~36.2s to ~33.5s
(in a 4-core VM.)
This only matters when the area exactly at the address is a reserved one,
which probably does not happen so often (this case is only used from
AreaRangeIterator at the moment.)
It was disabled because hoard2 triggered it far too often.
But now that we're using OpenBSD malloc with different glue,
this isn't an issue anymore.
Closes #18451.
Change-Id: I9a3b1190edbbe0ae3cedfe4df2993441d1f2d629
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8975
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
jam HaikuDepot with nothing to do, best of many runs:
hoard2
real 0m3.519s
user 0m3.348s
sys 0m0.159s
openbsd
real 0m3.481s
user 0m3.327s
sys 0m0.147s
time printf "continue\nsave-report\nquit\nk\n" | Debugger -c Debugger -s 1000
hoard2
real 0m2.295s
user 0m2.505s
sys 0m0.128s
openbsd
real 0m2.896s
user 0m2.809s
sys 0m0.579s
The performance difference in Debugger is due to OpenBSD malloc
actually decommitting memory. If we disable decommit, then
OpenBSD malloc is faster than hoard2 in this case also.
In some particular cases this is a huge speedup. For example, the link
of the "lto-dump" program in GCC seems to hit a pathological case in
hoard2 and our glue code for it; with hoard2 it takes around 23 seconds,
but with this allocator it takes only 2 seconds (!). Overall the
performance difference is much more modest, though.
Overall, system memory usage seems to be up about ~5% (318 MB -> 334 MB
just after boot), and that seems to mostly be due to the allocator
filling its initial caches faster when allocations occur, rather than
lazily allocating.
Change-Id: I071d8f76fbbfa11547bd6da6bf649d111414e780
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8974
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* PagesAllocator: A process-global caching strategy for the allocator.
It deals with allocating virtual addresses and memory, and gives us
back some of the performance that's lost by having an actual
decommitment strategy (which the hoard2 glue code doesn't.)
It uses two SplayTrees to manage free lists, and resizes areas
on allocate if they aren't next to a free chunk (which saves a lot of
time for large reallocations.)
There's still room for improvement here, see inline TODOs. But overall
we get pretty good performance with it.
* Add a TLS slot for the allocator glue to use. Right now it just puts
integers in there (since thread IDs are not evenly distributed),
but we could put a data structure pointer in there as well, potentially.
Change-Id: I56ddb0b022a468dc04275075ed7e174b339c8ca4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8335
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Exactly as-is. Modifications and integration will come in
the next commit.
Change-Id: I685483992d7f593fc46154ddea85a91798044faa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8973
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If we succeed in sending the message on the first try, then we don't
need to allocate anything at all.
This two allocations and a memcpy in the fast path (which is
hit the vast majority of the time, it appears.)
Some methods already did, but used a very large size of 16KB.
Reduce that to 4KB, do it in more places, and use BStackOrHeapArray
where possible.
Change-Id: Ia2d64582e76da6c1850e502107c07cb10bcd8226
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8969
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Rather than allocating a block in the constructor, just wait to
do it until we actually need to add items to the list. This saves
over 200,000 allocations when running "pkgman search" alone.
Change-Id: Ia6a21b963efded2bb4973edc2ba22ff026e01737
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8630
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Handle resizing areas past a reservation, fixing a longstanding TODO.
(The kernel address space implemenation still has the same TODO however.)
* Handle resizing areas past or inside more than one reservation at once.
* When an area shrinks, and it's touching/inside a reservation, expand
the reservation downwards at least to its original size.
Add tests for all these behaviors (they're passing.)
This is now obsolete as the preferred merge strategy is just to
copy the whole directories and then reinstate the __HAIKU__
directives, same as for the FreeBSD network drivers and other
such code.
This is used by some Tracker add-ons including TrackRunner and TrackGit.
Fixes #19386
Change-Id: I329eb9f1f8b2abf2872593d8f4417fa82de0b521
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8911
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Otherwise we'll try to write to some random register at or past the end.
Adjust the bitmasks: rename XHCI_LEGCTLSTS_DISABLE_SMI to RESERVED_BITS
and define it in hex. Also add the "read-only" bits as a separate
declaration, and don't touch those either; then remove the setting
of the "events SMI" bits.
We always did under EFI but not under BIOS. Now, the BIOS loader
reports the root pointer as well, so we don't need to find it again.
Change-Id: Ie83adb53f098d44f2688a1a327c084f94afa2673
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8941
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is necessary when the TEXT section is split.
At this point it may make more sense for libroot to register such
atexit hooks with runtime_loader rather than allocating them itself,
in line with the above comment's suggestion, but that can be investigated
some other time.
Previously this would simply tint the passed in background color.
After hrev58595 this was changed to pass the proper Foreground color instead.
The codepath to disable/enable the color was missed in an oversight,
this puts back the original tint color for the foreground aswell.
Fixes: #19406
Change-Id: I6f75d24316e8ca3ecdb78f11fc8dede88f082780
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8958
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... related to Pose and TextWidget not exactly matching.
Change-Id: Ic9c3f2ecc9a9dc4af4c200bc5a16b9f46d72f9b1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8954
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... by setting the incoming shortcut instead of the old one
in BMenuItem::SetShortcut().
Fixes #19405 a regression hrev58611.
Change-Id: Iecf19a323f6b6ead288e3f1ef1169376b11cddb3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8948
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
... by calling Install() on Go() in BPopUpMenu.
Install() prepares item shortcuts and set missing targets to the
target window. Combined with hrev58611 for regular menus this
passes most of the shortcut prep work on to BWindow.
Fixes pop up portion of #19395 a regression from hrev58589.
Change-Id: I8a1615502e0d6e0b75f9cd3ca2a45d08b53d11ce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8946
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: John Scipione <jscipione@gmail.com>
