Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Right, that's my issue. People keep claiming something is slow, but when I ask for an actual example they almost never come up with one, so I can't profile and fix it... ;)


sort by: page size:

Slow in what sense? I mean, for almost all actual use cases, it seems to be quick enough when done right.

It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.

That's something that needs proof from a profiler. Intuition on what's "slower" is really awful, particularly for JITed languages.

I don't think you could give general advice on what is slower as that's a constantly moving target.


I'm finding it instantaneous here on a large dirty codebase. In what way is it slow for you?

Very cool, thanks.

I totally agree with the fact that understanding the problem of slow application is a first what you need to do.


Agreed. I didn't mean that necessarily as a criticism of anything. Just hard to have an intuition for just how much it slows down.

I suppose there is a bit of something in there about using the right algorithm. But I can understand picking one that will take time for comparing speed. I'm not sure either is really representative of work you expect an editor to do, though. Curse of benchmarks.


If slower than absolutely necessary is a bug I can probably report 99% of lines in the codebase. Perfection is astonishingly difficult.

But you wouldn't have to track down performance issues in your code if it never was slow ;)

"Seems fast enough to me," when something is clearly slow.

So instead we're just not going to optimize anything, and every tool just gets slower and slower and slower.


Well, for starters, Amdahl's law exists. If you use design patterns that are 10x slower on a code path that takes only 0.5% of the execution time your application ends up 0.55% slower. And the profiler never tells you how faster can a code path be. It just tells you where are you spending most of your time so you can put the effort where it matters.

That would explain a lot! Sometimes when it's fast it spits out all code. When it's slower, it's Lazy! Thanks for the link

When a piece of code runs slow, the way to address that is to use a profiler to figure out where the slowness is coming from.

Perhaps it's worth trying to track what's the bottleneck in your workflow, compared with someone who is "faster", and then figuring out ways to remove those bottlenecks.


I'm sure that's a factor, but having slow tests makes it much harder to notice when you have made the actual code slower.

How so? I never thought of it as slow.

Source: Was a Meta infra engineer until last month, working in CDN & LogDevice, among other teams.


I mean, some code is all slow paths ;)

I didn't say it's just "slow". I said it's an expected performance hit in comparison with languages like C++. In some cases that hit is tolerable, in others not.

I wonder what makes it so slow then. I'm looking forward to the day when we can look at the source code :)

I guess we have different measures of slow, specially in a language that even comes with a REPL in the box.

There's always going to be slow code. That's a fact of life. That's also part of the "not really good at anything" point I made about general purpose computing. You complain about waiting seconds or minutes like it's outrageous. Instead sit back and think about what that computer is actually doing. I do, and I marvel that it only takes seconds or minutes.
next

Legal | privacy