Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
hey I'm going to talk about real-world review performance I'm it's a topic I'm very excited about so if i seemed excited up here it's because i'm excited um and hopefully it's the last talk of the conference for all of you I mean
it is the last talk of the conference from you not hopefully and and so I know you're all tired it's been a long couple days maybe you had a couple drinks maybe you stayed out late talking to people that's great so hopefully i can bring enough
energy to keep everyone awake that's my goal that's my only goal from this talk is everyone stays a week if you find yourself falling asleep just you know fall asleep just don't start snoring that will that will insult me that's okay but yeah
I think having the last talk on the last day is a little hard but I will get will get through together okay everybody um cool so first I just want to give a shout out before I start anything too there's a lot I could literally stand up here like wu-tang
and just shout out people all day but um but there are three people who worked on a number of tools and just worked on the Ruby language itself and made a lot of things possible in Ruby 21 that weren't possible before and are continuing to do that so I
want to give them a shout out 1 i'm on at github a good friend and from that picture you can see a very handsome gentleman Sam who I don't think it's a cartoon in real life I've never actually met but that's how I interact with him online
and co Ichi who's right there hey coach who's done amazing work I hope everyone saw his talk on the incremental garbage collector the other day which was pretty amazing sonus keeps our intro and not talk about myself first I'm going to go right
into the topic and i'll come back to myself later first I really want to say that this talk was actually heart pretty hard to write I've given a lot of talks and I also just want to say too who I saw a couple people mentioned imposter syndrome yesterday
and you know they see people like myself and maybe Aaron Patterson and even sandy get up and you think that they don't look nervous but I'm very nervous and I'm sure everyone else who gives a talk is still nervous so if you ever feel like giving
a talk just go up there give a talk please share what you're doing it's really important for the community so I've really learned a lot about performance and Ruby performance specifically over the past couple years in scaling a large application
and there's so much to share I didn't know what to talk about but when I started thinking about and started thinking about the tools I wanted to build in the tools I wanted to talk about I realized that tips and tricks are like cliff notes for tech
learning and Alex mentioned this in the previous talk figure in here but you know it's more important that I teach you ideals and philosophy then then snippets because I've been a mentor for the past couple years I've been growing this team I've
been working with a lot of junior developers and sure I could be like oh yeah don't use this method it's slow or don't do this it's slow but it's more important for me that I teach them how to do things not and think about how to do things
not just the individual snippets so if you walk away today I want you to come away with a process of of what I'm talking about not the actual tools because really ruby is moving fast the tools are moving fast everything in the community is moving fast
as sandy was saying maybe none of this stuff will be around in a couple years so but the process and the philosophy and how you approach problems will will stay with you the rest of your life so today we're going to talk about Ruby performance as therapy
I'm in psychotherapy I have been for the last couple years so I know a bit about this and if you're Jewish and you have interesting parents you're probably going through that same thing so but I want everyone to to relax and open up maybe close
your eyes for a minute don't close your eyes too long you're going to fall asleep and we're going to go deep because therapy in any format you know is a multi-step process and we're going to look at what a couple of steps and how they apply
to not only therapy for your code but there appear for yourself as you move through the code so step one of any therapy session is acceptance so it's your fault so I the Ruby performance it's your fault really yes yes it's your fault and in the
words of a famous philosopher it's not you it's me and what I mean by that is that performance is about context and when we talk about Ruby performance or any performance we have to talk about the context there was a lot of conversation a couple years
ago and it's still haunting a lot of us in here when someone said you know rails doesn't scale and that permeated the community and there was a lot of violence around it like emotional violence not actual physical violence and it's BS it's
why like how can you talk about anything I think there's been a lot of talks about this about context and about how we communicate with each other how can you talk about any type of performance problem when you don't not only talk about reproducibility
but the actual context that we're talking it the way i like to think about context sometimes is how i am talk to my parents about performance so when i go to my parents and I say we shaved a couple milliseconds off of a page they say how do you shave a
page right but then they also ask is that good you know they have no concept of what a couple milliseconds means in terms of web performance and I think that's the same when you're talking to anybody about any languages isn't Ruby's specific
but when we talk about Ruby being slow or rails being slow we're usually looking like a stack like this so you have rails in a single request is probably takes about 10 milliseconds of your time to just you know boot up or dispatch the request then you
have your application and go yeah it's a database or databases slow we should probably switch to some no sequel database because postgres takes 20 milliseconds then it's our memcache our memcache you know who knows how long that's going to take
but probably are only around 10 milliseconds so then we're left with your application which takes 250 milliseconds or whatever it is this is all relative obviously but you can see pretty clearly obviously this is a gross generalization but most likely
the time spent in any request you're doing if you're doing web performance is in your code so everyone together now just let's let's let this out it's my fault on three one two three ah that felt so good right whoo all right um so step
two once we've acknowledged that it's our fault is diagnosing the problem so in this case diagnosing the problem is where did where do I where did I go wrong not where did you go wrong not where did Ruby go wrong where did I go wrong so in order to
find out where I went wrong we need the 5 m's as i like to call them something that i just made up metrics measurements numbers and because milliseconds matter we're already collecting that you're already collecting metrics for everything right
everyone's collecting art recursion yeah okay good um because without metrics and without numbers and without justification for what we're doing what we think is slower we think is fast it's all just shootin fish in the darkened that's dangerous
um I know no I have no idea what you're in fishing the dark is like um so the point about this is that there are tools for every single type of performance problem you can possibly have and in Ruby 21 especially the tools are getting better and so well
I'll talk a little bit about the specifics is that later but I just want to say that any performance problem have theirs are there are tools for it step 3 once we've figured out kind of where the problem is or what we think the problem is then its
treatment which is what are the steps to fix this problem and the way I like to treat problems often is playing golf and by this i mean like vim golf and other golf type things it's it's how do you get the lowest number with the fewest number of strokes
or changes or lines of code and it's a kind of rinse and repeat methodology let's change this measure try it out scientific method basically and then confirm that it works or doesn't work and move on and when I talk about treatment I like to think
[ ... ]
Nota: se han omitido las otras 4.291 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.