Jump to content
Posted 14 September 2011 - 05:36 AM
Posted 14 September 2011 - 05:46 AM
Posted 14 September 2011 - 05:48 AM
Posted 14 September 2011 - 01:17 PM
Posted 14 September 2011 - 03:27 PM
Rendering information using printf style eplisis (...) set of arguments per frame. your performance will drop miserably.
Posted 14 September 2011 - 03:30 PM
Posted 14 September 2011 - 05:43 PM
Posted 15 September 2011 - 12:09 AM
Posted 15 September 2011 - 03:06 AM
Posted 15 September 2011 - 05:07 AM
I was ouputting from many points in my physics calcs per frame and my fps chunked down hard. the enitre game slowed considerably. it may have also been extra memory allocations occurring to field the ever expanding list of string forming console history.
Posted 17 September 2011 - 06:06 AM
Posted 17 September 2011 - 03:14 PM
Posted 19 September 2011 - 02:41 AM
printf("Hello %s stuff %d.\n", someString, someNumber);With something like (forgive my C, it may be rusty):
char buffer[N] = "Hello "; char *pointer = buffer; char intBuf[M]; pointer = strcat(pointer, someString); pointer = strcat(pointer, " stuff "); itoa(intBuf, someNum, M); pointer = strcat(pointer, intBuf); strcat(pointer, ".\n"); // Output "buffer"Essentially, it sounds like the printf formatting logic was inlined into every call site.
Doing something is always slower than doing nothing, certainly. I could see how such a level of optimisation would be necessary for a real time system like the phone system described, but it is unlikely to be the bottleneck, or even particularly problematic, in the OP's case.
Interpretation always adds more CPU work even as simple as printf's interpretor is
Posted 19 September 2011 - 03:13 AM
Posted 19 September 2011 - 03:28 AM
Whoops. I was trying to do as described here, but I forgot that regular strcat() does the retarded thing (I warned you my C was rusty!).
Either way, a decent (even a naive) implementation of the printf() family (including sprintf) would handily beat that. You have 4 calls to strcat() alone, which means walking the output string 4 times to find its length, strip the null terminator, then copy the new data to the end of the string; even a good strcat() implementation is going to struggle to beat a single pass through the input format specifier and a single pass at constructing the output buffer.
Posted 21 September 2011 - 06:18 AM
Posted 21 September 2011 - 09:31 AM
fancy_cout << 1234; // in assembly buffer = 1; buffer = 2; buffer = 3; buffer = 4;Don't remember where things eventually broke down and why. Maybe it even worked I just decided it was too much magic going on. Either way, it was never the bottleneck.