Given that EU tech salaries are a lot more tame, it would be interesting to see how 600m were even used. Hopefully there’s some good R&D there and not some French alps retreats and Porches for founders
Yes. All of Europe was working for them, and we're now entirely jobless. The industries, governments, all refocused on insects, and now it's gone. We don't know what to do. Send help.
Good article but seems strange that author benchmarked debug builds first, that’s a huge “no-no” in any perf tweaking and it’s clear that authors knows this well
From my experience, performance gains seen in Debug builds in Unity/C#/Mono nearly always translate in gains in Release mode. I know that this is not always true, but in this context that's my experience.
Setting up release benchmarks is much more complex and we develop the game in Debug mode, so it is very natural to get the first results there, and if promising, validate them in Release.
Also, since our team works in Debug mode, even gains that only speed things up in Debug mode are valuable for us, but I haven't encountered a case where I would see 20%+ perf gain in Debug mode that would not translate to Release mode.
I agreed with you initially, but is it really as big of a deal in C#? I'm used to compiled languages where "debug build" means "no compiler optimisations", aka every operation done with a variable is a memory load + store, trivial functions aren't inlined so even trivial accessors called in a loop carry function call overhead, etc etc. But this is C#, so the JIT presumably optimises just as much in a debug build as in a release build?
So in C++ terms, it's really just benchmarking "-O2" instead of "-O2 -DNDEBUG". This seems fine.
His bio says he was an Intel Fellow, which is like a VP-level individual role, and yes that's what I expected too… but apparently not? These are kinda low.
Id expect his comp even before Intel to be way above that (he came from Netflix), perhaps levels info is not entirely correct for Intel or doesn’t apply to exceptional hires, fellow level compensation at FAANG seems to be more accurate there though
I may have read your comment backwards but it seems rather wrong: react native DOES use native UI components, thats why it has “native” in its name. It’s also not compiled ahead of time per se, you still execute JS in the app (not in webview, yes) , but its mapped to native components
Thank you, it appears I was misinformed and/or conflating my knowledge of how flutter works. Mae culpa.
It does seem that many RN apps do React (not native) components when they need to do something custom, which may explain my sub-par, non-native experience with the RN apps I have used.
Even something “custom” is still a native component. The JSX you write eventually creates native views. Whether or not those views and components match the style and behavior of stock iOS or Android is a different story, and whether or not there are performance bottlenecks due to React Native’s bridge (now in theory no longer an issue because of a big architecture rewrite called Fabric) is another.
reply