
Ask HN: What do you first look for when diagnosing someone else's slow code? - webmaven
I always look for a loop in the application logic over the result of a database query that fires off another query for each row (sometimes to the same table, even), instead of using a join.<p>How about you?
======
cimmanom
Profile it.

If the profiler points to some awful thousand-line method and the cause isn't
obvious, add logging statements to record elapsed time at several points
within the method; use that to narrow down the cause.

Common culprits: nested loops (sometimes hidden by looping over function calls
that contain loops of their own); database abuse; calls out to third-party
services.

~~~
rajacombinator
This except I just manually log timer statements because I haven’t found a
profiler I like so far.

------
27182818284
To be honest it is usually what you mentioned and if any obvious indexes were
missed on the table.

After that it is generally a more formal investigation. Recently a coworker
massively (like more than 100x) improved a vendor's product when he found,
using an automated tool, that there was a huge area for improvement in the
generation of links on a particular page. You might have seen syntax like

    
    
        reverse('app1.view.view1')
    

in Django

or

    
    
        Html.ActionLink(...)
    

In MVC. Well this app had to do something similar, but at the scale it was now
doing it, its analogous method was far too slow and was really taking up the
most time on the page.

~~~
is_true
Which tool?

------
db48x
A profiler will pinpoint the source of performance problems even when you
can't recognize them by inspecting the source code.

------
matt_s
Loops, joins, making sure there are bind params used in queries so the DB
engine will recognize them as the same query, and make sure there are indexes
on columns being queried.

Also look at data volume. There may be much more data in table(s) after long
usage and long after the code was originally written.

If it is a high throughput application you should have monitoring in place
that can point you to where slowness may be. Some tools will having timings on
queries, loops, HTML/XML generation, etc. If not, get a profiler.

Also make sure you are up to date on the latest stable release of the stack
you are running. Performance or bug fixes might help.

------
amirathi
I check if there is a nice utility method to log timing information. If not, I
add one and sprinkle the code with timer logs. Push the change to production,
let it run for a bit, collect the logs & revert my commit. Easier to find
culprit this way.

Bonus point if you push timing information as metrics to cloudwatch or
whatever else you use. Important to look at stats like P90 for slow code that
is not reproduced every time.

------
1996
I first look at the whole sourcecode itself, then at the database schema. I
need to understand how it ticks.

I escalate only if I find nothing obvious, but most issues are obvious once I
have even a basic understanding of how it works.

As you said with the loop, there are only so many ways to do things. With
experience, you know them and their respective failure modes.

------
bjourne
I look for the basics. Is the code indented correctly? Consistent variable
names? Redundant logic? Good abstractions? Usually, after you have fixed the
basics whatever was the problem becomes obvious and trivial to fix.

------
ToFab123
I install a profiler, like Ants performance profiler [no affiliate], to see
what the code is doing.

