On 12/22/2011 11:32 AM, Jonathan M Davis wrote:
On Thursday, December 22, 2011 10:26:27 Walter Bright wrote:
PIMPL means you have an opaque pointer to something. It can be a function
pointer, or a data pointer. It gets filled in at runtime. It has nothing to
do with .di files.
Well, I have no idea how you'd do that in this case without hiding SysTime's
implementation,
Why not hide it?
since it has to call TimeZone's functions and therefore needs
to know that they exist. They're polymorphic, so the exact type of the
TimeZone could be unknown and unseen by SysTime, but it has to know about
TimeZone. And if you hid the function bodies in an effort to make TimeZone's
usage opaque, then you couldn't inline those functions anymore, and I would
consider the efficiency of the functions to be more important
Why is the efficiency of those functions important? I cannot think of an
application that needs high performance timezone calculations. (Benchmark timing
code does not need timezones.)
> that trying to
> avoid pulling in the TimeZone class just to avoid a few KB in the executable.
Kb in the executable does negatively impact performance.
The issue with something being only a few Kb is that when everyone thinks that,
we wind up with a 1Mb "hello world" program.
On Thursday, December 22, 2011 10:28:52 Walter Bright wrote:
The time zone info can be lazily initialized only by those operations that
need a time zone.
I don't think that that would really buy you anything. SysTime is default-
initialized to use LocalTime, which is a singleton, so it's not like you're
allocating a new TimeZone every time that you create or use a SysTime.
Currently, the singleton is initialized by a static constructor, but that's
going to be changed to be lazily initialized (which should get rid of the
static constructors and their cost). So, there _is_ still some cost on the
_first_ SysTime that gets created in the program, but after that, there isn't
really. And doing a lazy initialization of the TimeZone within the SysTime in
the case where the programmer does not specify a TimeZone would just increase
the cost of most of SysTime's functions, since most of them would have to be
checking whether the TimeZone had been initialized or not. With the singleton,
such a check only occurs when the SysTime is created. And at some point, the
singleton will probably be change to use emplace, which will allow it to
completely avoid the GC heap, which will make the singleton cost that much
less. So, the cost of the time zone from the perspective of execution speed is
minimal. It sounds like it's just the fact that using a class increases the
symbols in the executable that's the problem.
This conflates performance with allocated memory consumption and with static
memory consumption.
I am talking about minimizing the executable file size on disk.
