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, 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 that trying to avoid pulling in the TimeZone class just to avoid a few KB in the executable. 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. - Jonathan M Davis
