H. S. Teoh wrote:
On Mon, Feb 26, 2018 at 08:38:39PM +0200, ketmar via Digitalmars-d wrote:
H. S. Teoh wrote:
On Sat, Feb 24, 2018 at 09:43:35AM +0000, Stefan Koch via Digitalmars-d
wrote:
[...]
This particular slowdown happens because there are somehow
depdencies on std.format.format which is instantiated. Which has
a ton of dependencies itself.
Aha! That explains it. Thanks, Stefan, for the accurate diagnosis. :-)
Now the next problem is: how to trim the fat off std.format ...
p.s.: and ditch type safety. 'cause `foo(T...) (T args)` is a major
slowdown -- it is a template. ;-)
Actually, I think this is the classic example of why the compiler should
improve the way it implements templates.
In my mind, even C's printf API is sucky, because it involves runtime
parsing of what's usually a static string, over and over again. What we
*really* want is for something like:
writeln("blah %d bluh %s", i, s);
to be translated into something like:
stdout.putString("blah ");
stdout.putInt(i);
stdout.putString(" bluh ");
stdout.putString(s);
I.e., there should not be Yet Another Template with Yet Another
Ridiculously Long Argument List Type Encoded In The Mangled Name, along
with needless marshalling of function arguments on the stack, branching
to some other part of the code (potentially causing an instruction cache
miss), tons of copy-pasta for calling the same old functions for
outputting strings and formatting integers, and incurring Yet Another
Branch Hazard when the function finally returns.
And there should definitely be no silly runtime parsing of format
strings and all of that useless dance.
i once wrote such thing (for fun, using "Functional Programming With
Templates"). it was fun to do, and freakin' slow due to template bloat. ;-)
but yes, it generates a string mixin, and in runtime there was no format
string parsing.
still, we can be either smart, or have fast compile times, but not both. T_T
p.s.: oops. just found that i cannot pass structs with dtors to `(...)`
functions. not fun at all.
