21 May
2016
21 May
'16
8:59 a.m.
On May 21, 2016, at 4:33 AM, Mouse <mouse at
Rodents-Montreal.ORG> wrote:
Do you have reason to think dynamic-linker overhead is a perceptible
fraction of that delay?
Yes. (I think this is a Bad Thing, but I can see why they did it.)
Given that C is a systems implementation language, how would you
define HW related data structures where the order of the fields is
critical (ie HW defines them).
Most
executables are not performance-critical enough for
dynamic-linker overhead to matter. (For the few that are, or for
the few cases where lots are, yes, static linking can help.)
I keep telling myself
that whenever I launch Firefox after a reboot
... [file
formats and protocols]
First off, the C standard mandates that the order of fields
in a
struct cannot be reordered, so that just leaves padding and byte order to
deal with.
And data type size. (To pick a simple example, if your bytes are
nonets, you will have an interesting time generating an octet stream by
overlaying a struct onto a buffer.)
And alignment. Not all protocols and file formats place every datatype
at naturally-aligned boundaries in the octet stream. Now, it may sound cavalier of me, but of the
three compilers I use at
work (gcc, clang, Solaris Sun Works thingy) I know how to get them to
layout the structs exactly as I need them
Great. ...for code that doesn't mind writing off portability to other,
including future, hardware and compilers.
I still don't see why you're citing "it works for my work environment"
as justification for "the C standard should write off anything else?.