Hacker News new | past | comments | ask | show | jobs | submit | more seepel's comments login

It often breaks with different query parameters for example on YouTube videos, but I just created a couple of bookmarklets.

hn:

  javascript:window.location.href='https://hn.algolia.com?query='+encodeURIComponent(window.location.href)%20+%20'&page=0&dateRange=all&type=story'
reddit:

  javascript:(function()%7Bwindow.location.href%20%3D%20%22https%3A%2F%2Freddit.com%2Fsearch%3Fq%3Durl%3A%22%20%2B%20encodeURIComponent(window.location.href)%7D)()


I’ve noticed this problem in the npm ecosystem pertaining to typescript typings. Typescript is evolving really quickly, each new release allows you to be more expressive, and there are stricter and stricter settings to take advantage of. It’s fairly common for a third party library’s typings to be incompatible with new typescript settings. The problem is that maintainers are reluctant to add support in the name of backwards compatibility. The only solution I’ve found in some cases is to completely override the library’s typings myself locally.


On the other hand the same version supports indices on expressions that could be used to create an index on json values. Not exactly the same but could be used for similar use cases.


I believe there are actually some cool things they do with the extra space in the Objective-C runtime. It's been a while so I may be mistaken but I think they store the reference count in the pointer to avoid a lookup to a separate table. There might also be some trickery in storing NSNumber values in the pointer itself as well.

EDIT: Grammar


As the 64-bit CPUs used on the iPhone actually only have 33-bits of address space (undermining the benefits of having more address space ;P), Apple does use the extra space in a pointer to store "tagged" values in some cases, but for the most part this can be seen as a "mitigation": as the size of a pointer is now 64-bits, and as the alignment of a lot of things is now 64-bits because of that, processes are larger and heavier than on 32-bit systems, and thereby require more memory bandwidth. Sharing some of the bits of a pointer is essentially required to win back this lost performance. (Another great option is a 32-bit ABI using the 64-bit instruction set, as with x32 on Intel, but Apple did not go that direction.)


I think the problem is if you exercise the options after another financing round when the 409a will be higher. You then likely owe AMT on the difference of that value and your strike price.


It's not just about beauty, but experience. Imagine you have a spreadsheet with infinite rows where each row contributes to the Higgs mass. It also turns out that by and large each row contributes less than the previous. You can't calculate all of them, but calculating the bigger ones you can do pretty well. Now imagine someone plops in infinity into one of the rows, sure the rest could all just happen to contribute a small amount and conspire to add up and cancel that out (because the mass isn't infinite), but it just doesn't seem like the world we live in. However, if you add another column to your spreadsheet for super symmetry and suddenly that column naturally cancels out the discrepancies from the first column. It's a simplistic example, but hopefully gives a better idea why Physicists were hopefull for some kind of new physics.

This is called the hierarchy problem. https://en.wikipedia.org/wiki/Hierarchy_problem#The_Higgs_ma...


I'm a little late to the party, but I ran the benchmark inserts with cached statements on both my Macbook Pro and my iPhone 5S. sqlite definitely fairs better under this scenario.

That being said I still find the speed of Realm pretty impressive. And it's hard to gauge real world performance from this test. In my experience the real bottle necks around insert are upsets and establishing maintaining relationships.

For reference here are the benchmarks without reusing sqlite statements.

  Macbook Pro - Realm: 0.780414 sqlite: 0.464804 FMDB: 0.654659 
  iPhone 5S   - Realm: 2.235381 sqlite: 2.786381 FMDB: 3.336679
And with statement reuse

  Macbook Pro - Realm: 0.766406 sqlite: 0.189747 FMDB: 0.683823 
  iPhone 5S   - Realm: 2.214847 sqlite: 0.991864 FMDB: 2.832800
Interesting side note: FMDB seems to be spending just as much time finding the cached statement as sqlite takes to prepare a new one. I didn't expect that. I haven't dug into it at all, but I wouldn't be surprised if this due to the fact that the insert statement is relatively simple.

EDIT: Just fixed up formatting for the results


That's pretty cool, and roughly what I saw in my emulator - maybe my fumbling actually did it right :) And very much agreed, Realm is pretty impressive, and micro-benchmarks like this aren't all that useful.

Have you set up a pull request / issue by any chance? It paints Realm in a bit worse of a light, but hopefully they'll merge it in and update the site.


I didn't see the benchmark code in the repo, so I didn't really think about a pull request. Next time I find time I'll poke around a bit more. They are trivial changes though.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: