file and formatting alternative libs for c

Question

I've done some searching and have not found anything that would boost the file and formatting functions in Visual Studio VS2010 C (not C++). I've been able to address the raw i/o issues to some extent by using large buffers and a SSD drive, so the more pressing issue is a replacement for the family of printf functions. Has anyone found something worthwhile?

As I understand it, part of the glacial speed issue with the printf functions is that they have to handle myriad types of arguments. Does anyone have experience with writing a datatype-specific version of printf; eg, one that only prints ints, or only prints doubles, etc?

errr... your question s super vague. also the way printf handles the argument types is actually very tight code, and isn't a speed issue, the question i have for you is if you are doing something specialized why are you not using readv and writev instead? — Ahmed Masud, Feb 03 '12 at 17:16
Are you sure `printf` functions are your bottleneck? Have you measured it in any way? — Piotr Praszmo, Feb 03 '12 at 17:24
If your strings are very long, look into using a string lib that has (s)printf and a length indicator. When (s)printf is slow its typically because it spends a lot of time looking for the nul terminator. When I had this problem (way in the past), there were several C string libraries for handling the situation. I can't find any of them now. I suggest looking for "safe string library". — JimR, Feb 03 '12 at 19:11

score 1 · Accepted Answer · answered Feb 03 '12 at 19:04

First off, you should profile the code first before assuming it's printf.

But if you're sure it's printf and similar then you can do a few things to fix the issue.

1) print less. IE, don't call expensive operations as much if you can avoid it. Do you need all the output, for example?

2) manually replace the string concatenation with manually built routines that do all the pieces without having to parse the format specifier.

 EG: printf("--%s--", "really cool");

Can become:

 write(1, "--", 2);
 write(1, "really cool", 11);
 write(1, "--", 2);

That may be faster. But again, you won't know until you profile it. Don't spend energy on a solution till you can confirm it's the solution you need and be able to measure the success of your proposed solution.

score 0 · Answer 2 · edited May 23 '17 at 10:34

@Wes is right, never assume you know what you need to fix until you have proof. Where I differ is on the method of finding out. I and others use random pausing which works for these reasons, and here's a short slide show demo & C++ code so you can see how it works, if you want.

The thing about printf (or any output) function is it spends A) a certain number of CPU cycles creating a buffer to be output, and then it spends B) a certain amount of time waiting while the system and/or auxiliary hardware actually moves the data out.

That's maybe a bit over-simplified, but if you randomly pause and examine the state, that's what you see. What you've done by using large buffers and an SSD drive is reduce B, and that's good. That means of the time remaining, A is a larger fraction. You know that.

Now of the samples you find in A, you might get a hint of what's happening if you see what subordinate routines inside printf are showing up. Usually printf calls something like vprintf to get rid of the variable argument list, which then cycles over the format string to figure out what to do, including things like parsing precision specifiers. If it looks like that's what it's doing, then you know about how much time goes into parsing the format. On the other hand, if you see it inside a routine that is copying a string, or formatting an integer (along with dealing with leading/trailing characters, etc.) then you know to concentrate on that. On yet another hand, if you see it inside a routine that looks like it's formatting a floating point number (which is actually quite complicated), you know to concentrate on that.

Given all that, you want to know what I do? First, I ask who is going to read this anyway? If nobody really needs to read all this text, why not pump it out in binary? Or failing that, in hex? If you simply write binary, A shrinks to nothing, and when you read it back in with another program, guess what? No Lost Bits!

file and formatting alternative libs for c

2 Answers2