Hey /g/, I was asked to optimize this function in my interview

>>62438812
you are retarded or this is low quality bait.

>>62438812
doesn't this irreparably leak memory, since d gets incremented before it gets returned? can't be freed later....
you optimize it by firing the idiot that wrote it in the first place.

>>62438960

Sorry, I am writing it from memory. It should be:

char * d = calloc(1, 10);
char * ret = d;
...
return ret;

>>62438985
I dunno maybe something like
https://repl.it/LIKw/9
but i don't think it's actually an improvement.

>>62438841
ideas?

>>62438812

The fastest way to optimize that function is to turn around and walk the fuck out.

Stop supporting retarded hiring practices.

>>62439129
The interviewer made it seem like there was some loop unwinding, or caching the char array.

>>62439147
> "I don't want to get paid, I hate having a cushy job".

>>62439208
well that's loop unwinding, and we avoid modifying bar which is arguably a speed optimization. on 32-bit systems you're guaranteed that's all that will get filled in for d. on 64-bit systems you'll need a few more lines. c is weird that int can mean 32 or 64 bit. not sure what you mean by caching d.

>>62439238
So my guess was that rather than reallocation a fresh buffer each time, the function could be changed to accept it as a param.

void foo(int bar, char * d) {
  int k = 0;
  while (bar >0) {
    *d++ = bar & 0x7F;
    bar = bar >> 7;
    k++;
  }
  return k
} 

That way the caller could decide to alloc memory or not, rather than foo() assuming it. I think there may also be some SSE based parallel way of doing the loop, which would be faster than unwinding.

>>62439266
derp, that should be

int foo

, basically it returns how much it wrote.

>>62439266
I guess moving the allow outside might count, but it also changes the operation of the function. you're not optimizing, you're changing functionality.
expecting you to use SSE would be shitty, since you lose portability and end up rewriting it in another language (assembly)

>>62438812
You only need to allocate 5 bytes, the value will never be longer than 5.

>>62439372
it can use up to 9 bytes on 64-bit systems. int means the machine's word length, which can actually be anything... technically 10 bytes might not even be enough.

>>62438812
definitely get rid of that postfix increment - creates a temp char* unnecessarily.

Don't use calloc, use malloc. You're initializing parts of the buffer twice.

>>62439397

>int means the machine's word length
Sorry, that's not what int means. It's 32 bits on most 64-bit platforms. The only place it's 64 bits is on Tru64 Unix on a DEC Alpha machine. I'm pretty sure OP is not programming for an old defunct mainframe.

>>62438812
I feel like they f'd up and gave you the answer - the algorithm is converting 'bar' to base 128 and the most optimal way to do that is with bitwise AND and right shift operators. The only inefficiency I see is the postfix increment operator.

char* foo( int bar )
{
  char* ret = calloc( 1, 10 );
  
  for( char* d = ret; bar > 0; ++d, bar >>= 7 )
  {
    *d = bar & 0x7F;
  }
  
  return ret;
}

>>62439547
wrong.

File: ramen.gif (49KB, 200x210px) Image search: [Google]

49KB, 200x210px

>>62438812
I'm new, does *d++ dereference d and then increment it or does it increment d and then dereference it?