3 ms·

I don't, at least not when I care about performance. stdio is a big unknown with highly variable performance across platforms and libc-versions.

by geocar 7y ago

smabie 7y ago
Sure, yeah but it’s not like using printf is a problem for error messages or logging. Using write() for that kind of stuff is more hassle than it’s worth.
- geocar 7y ago
  Oh it so is! I can’t count the number of times I’ve gotten 20-50x speed ups just turning off logging. Assuming printf is free (or even cheap) is the sort of thing that’ll get you into trouble. It might not always matter, but when it does if your application is parsing strings at runtime at high volume, it’s going to hurt! I rarely log messages anyway, preferring to set state that I can then printout on command (e.g. siginfo)
  - jstimpfle 7y ago
    So did you just turn logging off, or did you in fact write a better custom implementation? And how much faster did it go? Did you actually measure that? What kind of system was that on? My first thought is, probably there was an fsync() or similar after logging each message. Also, printf() and friends have to lock the streams, so there might be some contention somewhere in case you're multi-threaded. That's not a problem that you can solve without some custom routing of logging messages. Using printf, you can easily write dozens of megabytes of the most complicated formatting code on contemporary systems (I'm just pulling a number out of thin air here). More than any system should want to log.
    - geocar 7y ago
      People who deal in megabytes have different problems than people who deal in petabytes. Usually just turn it off. At least at first. Note I’m talking diagnostic here; If I need the log messages obviously I have to write a custom streaming system even if the system printf is fast enough because the API complicates recovery. Printf can also vary in performance by 10msec or more based on the internal state. That’s not good enough since my entire application has a hard limit of around 30msec. I can’t even do one printf — even every N messages (for any N) because I’ll never catch up.
      - jstimpfle 7y ago
        > People who deal in megabytes have different problems than people who deal in petabytes. I just hope that this is not meant ad-hominem. At the very least it's a bad reply, unless you are dealing with petabytes per second. (Btw one of my current projects is a text editor that can handle gigabytes in memory; local operations take 5-50 microseconds. So I have reason to think I'm not entirely clueless). > I rarely log messages anyway, preferring to set state that I can then printout on command (e.g. siginfo) That sounds much more reasonable to me giving the volumes that you cite, and why shouldn't we use printf() for that? Why would printf "vary in performance by 10msec" or more, in ways that another application wouldn't? For how much data is that? How many printf() calls? Anyway I shouldn't have gotten in the woods here. The blanket statement that printf() is slow and therefore an obscure API like sbrk() is a better use, is nonsensical for a guide that seemingly gives general advice for memory allocation.
    - jstimpfle 7y ago
      > you can easily write dozens of megabytes I meant to add per second.
asveikau 7y ago
You might not. Your dependencies do. And maybe you do in small amounts. You think you are gaining something by misusing sbrk(2), but you are leaving a timebomb in your code. By your writing it seems like you are smart enough to know this. From a performance perspective, it won't matter in large amounts if you put a stack on a high level heap or mmap its pages or use this silly sbrk(2) thing. You know this.

I don't, at least not when I care about performance. stdio is a big unknown with highly variable performance across platforms and libc-versions.

by geocar 7y ago

I don't, at least not when I care about performance. stdio is a big unknown with highly variable performance across platforms and libc-versions.

smabie 7y ago

Sure, yeah but it’s not like using printf is a problem for error messages or logging. Using write() for that kind of stuff is more hassle than it’s worth.

geocar 7y ago
Oh it so is! I can’t count the number of times I’ve gotten 20-50x speed ups just turning off logging. Assuming printf is free (or even cheap) is the sort of thing that’ll get you into trouble. It might not always matter, but when it does if your application is parsing strings at runtime at high volume, it’s going to hurt! I rarely log messages anyway, preferring to set state that I can then printout on command (e.g. siginfo)
- jstimpfle 7y ago
  So did you just turn logging off, or did you in fact write a better custom implementation? And how much faster did it go? Did you actually measure that? What kind of system was that on? My first thought is, probably there was an fsync() or similar after logging each message. Also, printf() and friends have to lock the streams, so there might be some contention somewhere in case you're multi-threaded. That's not a problem that you can solve without some custom routing of logging messages. Using printf, you can easily write dozens of megabytes of the most complicated formatting code on contemporary systems (I'm just pulling a number out of thin air here). More than any system should want to log.
  - geocar 7y ago
    People who deal in megabytes have different problems than people who deal in petabytes. Usually just turn it off. At least at first. Note I’m talking diagnostic here; If I need the log messages obviously I have to write a custom streaming system even if the system printf is fast enough because the API complicates recovery. Printf can also vary in performance by 10msec or more based on the internal state. That’s not good enough since my entire application has a hard limit of around 30msec. I can’t even do one printf — even every N messages (for any N) because I’ll never catch up.
    - jstimpfle 7y ago
      > People who deal in megabytes have different problems than people who deal in petabytes. I just hope that this is not meant ad-hominem. At the very least it's a bad reply, unless you are dealing with petabytes per second. (Btw one of my current projects is a text editor that can handle gigabytes in memory; local operations take 5-50 microseconds. So I have reason to think I'm not entirely clueless). > I rarely log messages anyway, preferring to set state that I can then printout on command (e.g. siginfo) That sounds much more reasonable to me giving the volumes that you cite, and why shouldn't we use printf() for that? Why would printf "vary in performance by 10msec" or more, in ways that another application wouldn't? For how much data is that? How many printf() calls? Anyway I shouldn't have gotten in the woods here. The blanket statement that printf() is slow and therefore an obscure API like sbrk() is a better use, is nonsensical for a guide that seemingly gives general advice for memory allocation.
  - jstimpfle 7y ago
    > you can easily write dozens of megabytes I meant to add per second.

asveikau 7y ago

You might not. Your dependencies do. And maybe you do in small amounts. You think you are gaining something by misusing sbrk(2), but you are leaving a timebomb in your code. By your writing it seems like you are smart enough to know this. From a performance perspective, it won't matter in large amounts if you put a stack on a high level heap or mmap its pages or use this silly sbrk(2) thing. You know this.