News for hackers. Stuff that matters.
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @01:24PM (#15125935)
I type a sentence into the UI and it takes about 30 seconds for the text to appear, one character at a time. If I click anywhere else before the text has finished displaying, the text input continues from there, resulting in bizarre fragmentation.

Scrolling jumps under my mouse. It sometimes takes 3 or more tries for the UI to register that I've gripped a handle to drag a list item to a different location in the list.

This is in the latest Safari on a recent Mac laptop on a symmetric 50mbps connection.

Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @01:25PM (#15125945)
Thanks for letting us know. That sounds like an exceptional case from our metrics. Would you be willing to share your Asana user ID so we could learn more?
Re:Treating performance as a product: The technical story of... by riquito on Tuesday August 29, 2017 @03:41PM (#15127028)
It looks like a standard dark pattern in React, you are re-rendering more components than needed on certain inputs changes, you should ask him in which input he's typing, it would probably more useful than his user name
Re:Treating performance as a product: The technical story of... by blub on Wednesday August 30, 2017 @04:11AM (#15130502)
Anti-pattern. Dark patterns are tricks used to manipulate users.
Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @04:57PM (#15127542)
Thanks for the advice. Do you agree a potential optimization would be using React component state instead of store state?
Re:Treating performance as a product: The technical story of... by mikewhy on Tuesday August 29, 2017 @06:06PM (#15128027)
You should use React.PureComponent whenever possible. And stateless functions always re-render. There's no chance of using "shouldComponentUpdate".

Using store state vs local state shouldn't matter much, as long as your components are pure and only pull what they need from the store.

Re:Treating performance as a product: The technical story of... by azinman2 on Tuesday August 29, 2017 @05:45PM (#15127872)
Not trying to start a flame war, but do you know for sure “he” is a “he”?
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @06:29PM (#15128176)
You're right, it's not really germane to the primary topic of conversation in this thread, but thank you for noticing and pointing it out anyway. Fwiw, I'm a "she".
Re:Treating performance as a product: The technical story of... by azinman2 on Tuesday August 29, 2017 @11:11PM (#15129463)
Why am I being down voted? If anything, my suspicion it was an assumption was validated, and 'women in tech' is topic-du-jour.
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @04:53PM (#15127513)
It doesn't happen all the time - seems to be intermittent, but when it's happening, it'll go on for several minutes at a time. When it does happen, the activity monitor shows the browser process using basically the entire CPU.

Sometimes but not always, reloading the page fixes the problem; it does seem to be more likely to happen when the page has been open for an extended period, but sometimes the problem persists after a fresh page load. (There's one project that I use to organize most of my work, and I'm liable to leave that tab open to that project without reloading or even changing the sort/filter for weeks on end.)

Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @04:56PM (#15127540)
Thanks for the detail! Your description makes me wonder if there is a lurking memory leak.
Re:Treating performance as a product: The technical story of... by twobyfour on Wednesday August 30, 2017 @08:42AM (#15131594)
What seems to happen is that memory usage spikes (by as much as 100 MB) alongside CPU usage while the typing lag is occurring, and then it drops back to baseline as soon as the text is displayed properly.
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @05:01PM (#15127570)
Memory usage seems pretty stable, but I'll make a note to check that next time the issue occurs.
Re:Treating performance as a product: The technical story of... by kevan on Tuesday August 29, 2017 @02:09PM (#15126330)
Out of curiosity, are you watching percentiles or averages in your metrics?
Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @02:13PM (#15126360)
We used to track percentiles but discovered Asanas struggled to empathize with them. We switched to defining semantic performance bands (eg < 100ms, < 300ms, < 1s, < 3s, < 5s, < 10s). For each action, we track the percentage per band. Asanas seemed to empathize better with time as the independent variable and percentage as the dependent variable.
Re:Treating performance as a product: The technical story of... by btilly on Tuesday August 29, 2017 @02:30PM (#15126513)
I would also suggest that you do the same with a metric for "slowest action in 15 minute period of user input". 99% of actions are fast but you have hundreds of actions over 15 minutes, people will notice those slow ones.
Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @02:36PM (#15126556)
Thanks for the advice! We believe that users remember the slowest actions as well. Your strategy sounds like it will help identify the long tail of rare yet slow actions.
Re:Treating performance as a product: The technical story of... by btilly on Tuesday August 29, 2017 @04:36PM (#15127410)
Here is another tip to track down that long tail.

"Tracer bullets". Have a flag that can be put on an action that causes it to be logged very verbosely. In a way that travels through your system. And then aggregate those logs, process them, and make them available. Then randomly tag a small fraction of actions with that flag. Like 0.1%. Because you do this relatively rarely, you can make verbose logs without overwhelming your system.

When you receive a complaint about foo occasionally being slow your first stop is to see if you've got a concrete action that was slow, look at the picture from the logs, and try to figure out why. This will greatly help in reproducing rare problems or, if you can't, at least identifying where they come from deep in your system.

Re:Treating performance as a product: The technical story of... by f1notformula1 on Tuesday August 29, 2017 @02:24PM (#15126463)
Can you elaborate on what an Asana is and what "empathize" means? I'm not an Asana user, so perhaps I'm unfamiliar with the jargon.
Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @02:27PM (#15126494)
By Asana, I just meant employee. More people intuitively understood our metrics when we switched our framing.
Re:Treating performance as a product: The technical story of... by btilly on Tuesday August 29, 2017 @02:31PM (#15126521)
Another benefit of switching that framing is that it makes aggregation easier.
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @02:30PM (#15126518)
Yes, but not publicly.
Re:Treating performance as a product: The technical story of... by pspeter3 on Tuesday August 29, 2017 @02:41PM (#15126604)
Thanks! Please feel free to email me at [email protected], message me on Twitter, or let me know what works best for you.
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @04:55PM (#15127531)
I appreciate your reaching out about solving this! I'll be in touch later in the week.
Re:Treating performance as a product: The technical story of... by CodeWriter23 on Tuesday August 29, 2017 @04:59PM (#15127560)
You can't use your metrics to discern their Asana ID? Or just any customer having severe performance issues? Hmmm...
Re:Treating performance as a product: The technical story of... by twobyfour on Tuesday August 29, 2017 @04:54PM (#15127525)
Out of curiosity, is this getting upvotes because other people are experiencing the same thing, or for some other reason?