151–160 of 161 posts
Earlier quoted context omitted.
> Optimizing for speed usually causes increased memory consumption, Lol, no? If your benchmark is memory bound, reducing memory usage is probably the simplest way to make it faster.
He is right though. Chrome isn't memory bound... yet.
Earlier quoted context omitted.
https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc Look at DOM performance. Chrome has a ceiling of about 45m ops/s where FF max speed is dependent upon your ram and bus speed reaching beyond 4-5b ops/s. In both though querySelectors perform at about the same speeds as slow as 25000 ops/s. I have written an OS GUI that executes in the browser. It loads, including full state restoration in about 120ms. I was…
> "I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed." How is this possible? OS should be using direct syscalls, any additional code you write should be pure overhead in theory, right?
With the DOM querySelectors are dramatically slower than using static methods with arbitrary strings as arguments. This is likely because a query string must be parsed against each child node to determine if the child node is a match to the supplied query. Likewise, modern OSs use ancient conventions to search the file system, such as wildcards, along with more modern advanced search syntax. These are rules that must be parsed against each child artifact from a tree segment. My application deliberately doesn't do that.
To compound matters Windows, don't know about OSX, caches search results so that subsequent searches are a little less slow, which incurs a greater performance penalty on first search. My application doesn't do that either. Each search triggers tree traversal, so its always as fast reading from the file system.
Mentioning any of this during a job interview makes for intriguing conversation with the interviewer. I do detect genuine interest and curiosity from the interviewer. At the same time they know their team will fight to the death at many mention of alternatives to querySelectors and/or JSX, so you have just effectively terminated the interview. Anything there after is purely for the interviewer's personal interests.
Earlier quoted context omitted.
I have been doing web work for over 20 years. Everybody claims to care about performance, training, security, and so forth. The only thing that really matters in practice is comfort. Until developers are willing to abandon certain areas of comfort things like performance are only given lip service. In doesn’t matter what they want if they are actively working in opposition. This is performance is a massive incompatib…
> In doesn’t matter what they want if they are actively working in opposition. This is performance is a massive incompatibility to hiring. No one is working towards degrading performance on purpose, and caring about performance is not "a massive incompatibility to hiring". But the fact that you keep stating this makes it clear that there seems to be plenty of other reasons organizations are not hiring you.
You are not participating in the same interviews that I am then. Most developers know querySelectors, for example, are super slow. They will fight to death to retain them and anybody who suggests any alternative is not compatible for hiring. If they know its slow and deliberately choose to avoid faster alternatives how is that not degrading performance on purpose? How is that not common?
IMO Chrome desperately needs to minimize its memory usage.
Memory is like $3-4/GB (decently fast DDR4). And you've been fine with 16GB for a decade without upgrading. If you're stuck on some un-upgradable old budget device, it's unlikely the memory holding you back either.
I have 64GB of memory total and about 16-32 of it is in use for virtual machines, which is reasonable.
How much total memory do you expect the average computer to have?
Earlier quoted context omitted.
I suspect that isn't why you weren't hired.
Why would you suspect that? Are you a JavaScript developer? If so have you seen the terrifying horror on people’s faces when you mention alternatives to querySelectors or that you can write/execute code faster by not using vDOM? Mentioning performance is the fastest way to exit a job interview.
I think that browser developers are optimizing the wrong thing. Specifically: they optimize for execution speed while they better optimize for minimum memory usage instead. Let me explain why this is more important. Let's say I am visiting a properly made website and it takes 10% of CPU to render. Even if browser devs make their browser twice faster, it will only save 5% of CPU time - and that would be completely unn…
I disagree. Memory is cheap. Battery life isn't.
Am I so wrong to stop reading after a grammatical error on the very first word in the article? https://www.google.com/search?q=everyday+two+words+or+one
I have a friend who says: "when you invent more efficient lightbulbs, people do not consume less energy, they just get more light" Every time we did a milestone performance improvement in our infrastructure, e.g. search used to take few seconds, we reduced it to few milliseconds. One year later our colleagues were doing machinegun-like queries and the search was back to take 1 second, and it is just a matter of time…
Relevantly, here's the HTTP Archive's chart of page weights over time: https://httparchive.org/reports/page-weight#bytesTotal The median is around 2MB, up from 1.5MB 5 years ago.
Earlier quoted context omitted.
> "I was recently interviewing with a search engine company, one of the big ones, where I could demonstrate that JavaScript tool can execute file system search much faster than the OS and produce better results. They seemed really impressed." How is this possible? OS should be using direct syscalls, any additional code you write should be pure overhead in theory, right?
No, its a common misunderstanding of search and tree models. The OS is faster, by a tiny bit, at traversing the file system than my JavaScript application. It is only search that is slower, and dramatically so. I don't have visibility of the OS code so I cannot be certain why that is. I speculate its because the OS is doing too much. With the DOM querySelectors are dramatically slower than using static methods with a…
Earlier quoted context omitted.
I have two identical laptops, one with 8 GiB and the other with 32 GiB of RAM. The former lasts over 2 weeks in S3, the latter not even a week.
Identical as in model, hw and configrations except memory?