0

I have a string-typed deque initialised, and with a string in it, ie in my main function:

deque<string> d;

I know that I can use this to output using iostream library,

for(string n : d)
   cout << n;

However, I know trying to use the cstdio library to output the string. One way that I know which works is

for(i = 0; i < d.size(); i++) 
   printf("%s", d.at(i).c_str());

However, that seems to be much slower than I thought (by means of submitting to an online judge), and thus I am wondering if there is a way to print the string using cstdio library in a way that is faster than the above!

Addendum: The code which mixed cstdio with iostream was the fastest, ie

scanf("%s", str);
s = string(str);
...
for(string n : d)
    cout << n;

The second fastest was pure iostream, ie

cin >> s
...
for(string n : d)
    cout << n;

The slowest was pure cstdio, ie

scanf("%s", str);
s = string(str);
...
for(i = 0; i < d.size(); i++) 
   printf("%s", d.at(i).c_str());

Addendum 2: I mentioned measurement of speed and in this case it was the output of "CPU speed" by the Kattis online judge after each submission of code. No other forms of measurement were used. Would it be true that for e.g., many users were submitting their codes at the same time, then CPU time would increase? I am ignorant on how it is measured, and thus posing this question at the same time.

Many thanks for any input.

Tammy Von
  • 1
  • 1
  • How you use the string doesn't affect whether you can use a range-based for loop, unless you're dealing with something like removing elements while iterating. – chris Feb 03 '18 at 08:21
  • 2
    The first piece of code makes a copy of each string, the second one does not. The first one uses iostream library which in general is found to be somewhat slower than cstdio (because of the extra features). Yet the second one runs slower? That is interesting. How did you measure that? Also what do you mean with *print the string (only 1)*? – stijn Feb 03 '18 at 08:22
  • In general (for questions about performance): Did you test without debug options and with "full" optimization? Time measurement in debug mode is not relevant. (In debug mode, additional "guardian" code may come into effect.) – Scheff's Cat Feb 03 '18 at 08:26
  • @chris Understood; I wasn't intending to remove or modify any elements while iterating in this case. – Tammy Von Feb 03 '18 at 08:44
  • @stijn - Measured by means of an online judge, with the rest of the code being exactly the same. Not exactly the best way of judging the speed I suppose. I apologise for the confusion with the parenthesis remarks, and have removed them. – Tammy Von Feb 03 '18 at 08:46
  • @Scheff I tested it using simply by submitting the code to an online judge for a particular problem. – Tammy Von Feb 03 '18 at 08:46
  • 1
    "Measured by means of an online judge" What’s an online judge? How do they work? What data did you get from them? When judging performance the *exact* details about your compilation and measuring process are crucial to evaluate the results. Without those details you don’t measure, you speculate wildly. – besc Feb 03 '18 at 08:51
  • I'm not sure what you mean with "online judge". (Could you provide a link?) If you meant something like [coliru.stacked-crooked.com](http://coliru.stacked-crooked.com/) - check whether you can activate optimization and suppress debug info. The compile command of coliru is (in my case) `g++ -std=c++17 -O2 -Wall -pedantic -pthread main.cpp && ./a.out`. `-O2` ... strong optimization. (I believe there is also `-O3` which is not recommended in any case.) Also, the `-g` for debug info is missing. This would be a good setting for performance measurement. – Scheff's Cat Feb 03 '18 at 08:54
  • May be, you could offer a [mcve] to expose also _how_ you measure the time. – Scheff's Cat Feb 03 '18 at 08:56
  • In your examples after "Edit:", the only difference between 1st and 2nd sample code is how input is done. Did you "automate" the input (e.g. by piping, re-directing standard in). Probably you had to, if you used an online compiler. – Scheff's Cat Feb 03 '18 at 08:58
  • @Scheff Thanks for guiding, I used the Kattis online judge to be exact. The page for C++ is found here: https://open.kattis.com/help/cpp. It is mentioned that "For C++, we use gcc version g++ (Ubuntu 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609 with the following flags: -g -O2 -static -std=gnu++11 {files}." How I measured the time was simply by the CPU time posted by Kattis on my code after each submission. – Tammy Von Feb 03 '18 at 09:03
  • "the time was simply by the CPU time posted by Kattis" - something I wouldn't trust too much. So, it probably measures start-up time also. This might differ due to the libraries which are pulled in. The linked libraries in turn may depend on used symbols which, of course, differ if you once use c-stdio and once C++ I/O. In short, you got a lot of "noise" in your measurement. – Scheff's Cat Feb 03 '18 at 09:11
  • @Scheff - thank you so much! :) – Tammy Von Feb 03 '18 at 09:16
  • This question might be interesting/inspiring: [C++ iostream vs. C stdio performance/overhead](https://stackoverflow.com/q/37894262/7478597). (Btw. the linked question trusts on OS measurement.) Please note, the hot discussions in that Q/A. Actually, performance measurement is not quite easy - a lot which can be done wrong. – Scheff's Cat Feb 03 '18 at 09:17
  • Roger that, thank you! – Tammy Von Feb 03 '18 at 09:19
  • If you want to find more: I googled "stackoverflow C++ stdio stream performance". ;-) – Scheff's Cat Feb 03 '18 at 09:19
  • Which Kattis problem is this? – ggorlen Sep 23 '22 at 03:10

0 Answers0