Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It Can Happen to You

mattkeeter.com

Post reply on HN
Print view View original

331–340 of 419 posts

Re: It Can Happen to You

#331

Post by OskarS »

dorgo wrote: post #189
alexchamberlain wrote: post #166

Earlier quoted context omitted.

It makes me chuckle when hash maps are stated to be O(1) insertions. Which is true, in respect to the number of items in the map, assuming the map doesn't need resizing and there isn't a hash collision... but it's generally not true in respect to the key length. (I think most implementations are O(ln), where l is the length of the key and n is the number of inserted items, assuming the hash function is O(l) - the _am…

But, isn't the key length a constant and we are back to O(1)? Ok, in theory you could exhaust all possible keys of a certain length and proceed with longer keys. It would give us what? O(ln(n))?

His point is, if you use Moby Dick as the key, it's going to take longer to hash that than a three letter string. Hashing isn't O(1) if the key has variable size.

Re: It Can Happen to You

#332

Post by Jyaif »

smallnamespace wrote: post #179
Jyaif wrote: post #147

Earlier quoted context omitted.

Can you point me towards some source code where a human can't find the algorithmic complexity?

Humans can't tell you whether this program will run forever on any particular (positive integer) input, or whether all inputs terminate. def collatz(n): while n != 1: print(n) if n % 2 == 0: n = n // 2 else: n = n * 3 + 1 print(1)

Thank you!

Re: It Can Happen to You

#333

Post by hyperpape »

layer8 wrote: post #289
Gibbon1 wrote: post #256

Earlier quoted context omitted.

It's even more flabbergasting that all these problems haven't been fixed.

That would likely break backward compatibility of existing implementation-defined behavior.

Converting sscanf from undefined to implementation defined behavior would, by definition, not break implementation defined behaviors.

There are real cases where removing undefined behavior blocks optimizations, but this doesn't feel like one.

Re: It Can Happen to You

#334

Post by froh »

I wonder if then The Right Way of scanf-scanning potentially large strings is the fmemopen route?

  /* ... goal: scanf some looong char *s in some loop */

  FILE *s_as_FILE = fmemopen(s, strlen(s), "r");
  /* loop loop loop */ ... {
      fscanf(s_as_FILE, "FORMAT", &v);
  }
  fclose(s_as_FILE);
fmemopen is around for a while now, it should work with many libc implementations these days.

?

Re: It Can Happen to You

#335

Post by beart »

There are currentely 19 million + results when searching for code using sscanf on github. I wonder how many of those are suffering under the same problem.

Re: It Can Happen to You

#336

Post by bobbylarrybobby »

codetrotter wrote: post #247

I am writing an app for iOS in Swift and I have an array of structs with some 70,000 elements or thereabouts and for some bizarre reason the compiler uses so much memory if I define it as such directly in the source, that I run out of memory. So instead as a workaround for now I am storing the data as a JSON string that I parse at runtime. It’s very sad, but it’s the only option I had because I have a ton of other co…

Do you explicitly indicate the type of the array? E.G., `let array: [Bazinga] = [ … 70k elements …]` instead of `let array = [ … 70k elements …]`.

Re: It Can Happen to You

#337

Post by wpietri »

lostcolony wrote: post #322
simias wrote: post #320

I think the really embarrassing part for Rockstar is that they didn't bother to investigate what took 5+ minutes to load in their star product, a simple profiling would've made the issue obvious. So either they knew and they didn't care, or they didn't know and they didn't care. That being said both for GTA and for TFA the issue is a very similar sscanf call: sscanf(data, "%f", &f); I already posted a similar comment…

I think 'embarrassing' is too strong a word. AAA game development is rushed; the pressure is to ship. Something has to give. This is a user facing issue, but one that doesn't actually affect the gameplay. Assuming they had -time- to profile the load process, given that low a priority, seems extremely optimistic.

Well, it doesn't affect the gameplay if the player starts the game once and never closes it. But for anybody who wants to hop on for a quick bit of fun, it's a notable barrier. There are definitely games I've stopped playing because it takes too much time to launch the thing.

Re: It Can Happen to You

#338

Post by ajmurmann »

Hamuko wrote: post #323
lostcolony wrote: post #322

Earlier quoted context omitted.

I think 'embarrassing' is too strong a word. AAA game development is rushed; the pressure is to ship. Something has to give. This is a user facing issue, but one that doesn't actually affect the gameplay. Assuming they had -time- to profile the load process, given that low a priority, seems extremely optimistic.

> AAA game development is rushed; the pressure is to ship. I'd be more understanding if GTA Online hadn't already shipped its first version in October of 2013. Surely there would've been some time after shipping the first version to profile the game.

(disclaimer: I'm not in game development and only read about this)

Usually different staff rolls on and off at different times of product development and post-release lifecycle. I understand that most programmers would have been rolled off a while before launch. You early on have people build or adjust the engine and tooling, but later on you don't need most of them anymore and things come down to creating content.

Re: It Can Happen to You

#340

Post by acomjean »

lostcolony wrote: post #322
simias wrote: post #320

I think the really embarrassing part for Rockstar is that they didn't bother to investigate what took 5+ minutes to load in their star product, a simple profiling would've made the issue obvious. So either they knew and they didn't care, or they didn't know and they didn't care. That being said both for GTA and for TFA the issue is a very similar sscanf call: sscanf(data, "%f", &f); I already posted a similar comment…

I think 'embarrassing' is too strong a word. AAA game development is rushed; the pressure is to ship. Something has to give. This is a user facing issue, but one that doesn't actually affect the gameplay. Assuming they had -time- to profile the load process, given that low a priority, seems extremely optimistic.

I tend to agree. When you are rushing things get missed. Also if it was a problem from the beginning you just might not think its an issue (its just how long it takes) .

One philosophy I heard in my days of programming (not sure how I remembered this but its still out there) :

Make it work, make it right, make it fast. -- Kent Beck

Post reply on HN