That 1MB is allocation done by code generation. And this generates the code every time it runs. That's why it's bad.
On Tue, Sep 22, 2015 at 8:10 PM, Daniel Carrera <[email protected]> wrote: > Really? What does it *DO* that needs 1MB? I admit I don't really know how > it works. I have tried to learn macros, but I still think they are > basically black magic. > > > On 22 September 2015 at 22:37, Stefan Karpinski <[email protected]> > wrote: > >> It also allocates 1MB just to print three numbers. Yikes. >> >> On Tue, Sep 22, 2015 at 4:34 PM, Daniel Carrera <[email protected]> >> wrote: >> >>> Hmm... I know it's horrible, but I just added that to my juliarc file :-) >>> >>> This function is 100x slower than the macro, at about 100 lines in 0.5s. >>> I know that's horribly slow for traditional printf() but it's fast enough >>> for terminal output. >>> >>> >>> >>> On 22 September 2015 at 22:06, Stefan Karpinski <[email protected]> >>> wrote: >>> >>>> Possible, but I don't relish the thought of forever explaining to >>>> people that they need to use printf with or without the @ depending on if >>>> they want it to be fast or flexible. If you really don't care about speed, >>>> you can just do this right now: >>>> >>>> printf(fmt::AbstractString, args...) = @eval >>>> @printf($(bytestring(fmt)), $(args...)) >>>> >>>> >>>> But actually don't do that because it's so horrifically slow and >>>> inefficient I just can't. >>>> >>>> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On 22 September 2015 at 20:40, Stefan Karpinski <[email protected]> >>>>> wrote: >>>>> >>>>>> I think that before any further discussion takes place of how easy or >>>>>> hard implementing a high-performance printf is, anyone who'd like to >>>>>> comment should spend some time perusing GNU libc's vfprintf >>>>>> implementation >>>>>> <http://repo.or.cz/w/glibc.git/blob/ec999b8e5ede67f42759657beb8c5fef87c8cc63:/stdio-common/vfprintf.c>. >>>>>> This code is neither easy nor trivial – it's batsh*t crazy. >>>>>> >>>>> >>>>> That is insane... 2388 lines, half of it macros, and I have no idea >>>>> how it works. >>>>> >>>>> >>>>> >>>>>> And we want to match its performance yet be much more flexible and >>>>>> generic. The current printf implementation does just that, while being >>>>>> somewhat less insane GNU's printf code. If someone has bright ideas for >>>>>> how >>>>>> to *also* allow runtime format specification without sacrificing >>>>>> performance or generality, I'm all ears. >>>>>> >>>>> >>>>> >>>>> This might be a stupid question, but what's the harm in sacrificing >>>>> performance as long as we keep the current @sprintf for scenarios that >>>>> call >>>>> for performance? I don't always need printf() to be fast. >>>>> >>>>> >>>>> >>>>> >>>>>> I have some thoughts, but they're just that – thoughts. One option is >>>>>> to change the design and avoid printf-style formatting altogether. But >>>>>> then >>>>>> I'm sure I'll never hear the end of it with people kvetching about how we >>>>>> don't have printf. >>>>>> >>>>> >>>>> Probably. Everyone is used to printf and they are comfortable with it. >>>>> >>>>> Daniel. >>>>> >>>> >>>> >>> >> >
