|
|
Subscribe / Log in / New account

GObject type system: slow?

GObject type system: slow?

Posted Aug 20, 2025 8:55 UTC (Wed) by linuxrocks123 (subscriber, #34648)
In reply to: GObject type system: slow? by mathstuf
Parent article: Hashimoto: We rewrote the Ghostty GTK application

> IME, much of the perf benefit comes from not having to call `strlen` on every C-string API. For example, comparisons can short-circuit on length comparisons instead of doing some `memcmp` SIMD shenanigans.

strlen is supposted to constexpr for string literals, so what you said didn't make sense to me. I tried it out on my machine just now to make sure:

---

#include <string>

using namespace std;

bool is_elf_friend(string x)
{
return x=="mellon";
}

---

This compiles to:

---

_Z13is_elf_friendNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE:
.LFB1425:
.cfi_startproc
xorl %eax, %eax
cmpq $6, 8(%rdi)
je .L7
ret
.p2align 4,,10
.p2align 3
.L7:
movq (%rdi), %rax
cmpl $1819043181, (%rax)
je .L8
.L3:
movl $1, %eax
.L4:
testl %eax, %eax
sete %al
ret
.p2align 4,,10
.p2align 3
.L8:
cmpw $28271, 4(%rax)
jne .L3
xorl %eax, %eax
jmp .L4
.cfi_endproc

---

That cmpq $6 instruction is doing an obvious immediate comparison based on the length of "mellon", followed by an early return if the length of the parameter does not match. So, I don't think you're correct.


to post comments

GObject type system: slow?

Posted Aug 21, 2025 13:45 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Perhaps things have changed? I was doing callgrind-guided optimization and sought out places doing `strlen` oodles of times (or with it being a large percentage of a function's call stack). But this was back in 2013 or so; compilers could certainly have improved since then.

Even without that, the different connotations implied at the API boundaries are still useful regardless IMO.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds