Suggest modification to this talk

Title

Description

The talk is a narrative retelling of how I took an application that needed to communicate with a slow external API and improved the user's experience in terms of speed. I'll talk about the situation that we started with, and then retell the story of measurement, and improvement and measurement and improvement.

I'll talk about perftools.rb, improving the perception of speed without having to actually make your code faster, MRI's Threads (when they're a good fit, and how and why we used them), a few strategies for managing threads, and a few other related topics. None of these topics will be discussed in great depth; the format is intended to be a retelling of the project, so I'll limit my discussion to the scope of how it applied to this specific project.

The talk will probably be of most interest to people who have little real-world experience with MRI's Threads and/or making users feel like an application is responding quickly. My hope is that showing these things in the context of a real project can help solidify understanding of topics that are often covered in contrived or theoretical examples (I know it did for me: I was totally new to a lot of this stuff when I started the project).

Help us caption & translate this video!

http://amara.org/v/FG8o/

Date

Summarized using AI?

If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.

Show "Summarized using AI" badge on summary page

Summary

Markdown supported

In the talk titled "I Made a Slow Thing Fast," Ben Hamill narrates his experience in enhancing application performance in Ruby by addressing user experience with slow external API communication. This session, presented at the LoneStarRuby Conf 2013, highlights the complexity of dealing with performance issues, particularly the perception of speed versus actual speed improvements.

Key Points Discussed:
- **Initial Codebase and Challenges**: Hamill describes the initial state of the codebase as intimidating but manageable, focusing on improving the user experience during synchronization with a slow external API.
- **Measuring Performance**: He emphasizes the importance of measurement and investigation to identify performance bottlenecks rather than making assumptions about where the problems lie. Tools like 'top,' 'iostat,' and 'perftools.rb' were useful in pinpointing issues with network-related actions and disk usage.
- **Creating the Illusion of Speed**: Hamill shares strategies for enhancing the perceived performance without making significant changes to the codebase. These include prioritizing recent changes, eliminating unnecessary API calls, and optimizing update-processing to provide quicker feedback to users.
- **Implementing Threading for Performance**: As a next step towards real performance improvement, Hamill explores multithreading with Python's Global Interpreter Lock (GIL) in mind. He successfully implemented a persistent thread pool to manage tasks more efficiently, which resulted in further reductions in synchronization times.
- **Results and Reflection**: The changes led to a substantial decrease in user feedback time, from 15 minutes to 17 seconds over a week of implementation. While this pace still needed improvement, it marked a significant enhancement.

Conclusions and Takeaways:
- Identify specific bottlenecks using appropriate tools to inform optimization steps.
- Consider optimizing user feedback and input-output management as immediate ways to boost perceived speed.
- When necessary, thoughtfully incorporate threading to tackle performance challenges, keeping in mind the balance between complexity and efficiency.

Ben Hamill's insightful narrative offers newcomers valuable lessons in performance optimization and the critical balance between perception and reality in application responsiveness.

Cancel