Does anybody really use a Profiler?
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
Any reason why parametrized SQL code would be slower than a stored procedure? I mean, unless your statement is so big that the network overhead of sending it would be significant, a parametrized statement would have its execution plan cached by the server, same as the stored procedure. Of course it's a lot more interesting to get all the results you need in one statement instead of looping over every row and issuing a SQL statement for every row. Same goes for LDAP.
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
I rarely use profilers, but there are a few cases when even good programmers may have trouble seeing where code is slow. Sometimes there may be a library call which you think will be fast, but turns out to be slow. This could be due to system call(s) that take longer than the programmer realizes or due to the library function's algorithm working very differently than the programmer realized. We all make assumptions about things that sometimes aren't true. One very big issue is using something like using strlen(some_string) as a constant in a C program. Many programmers use that as though it is a constant in the compiler's mind, when it may not be (GCC has an __attribute__ that lets the compiler see that it is, but it's not standard). That's the kind of thing that could end up in a loop, possibly as part of the loop check, without many programmers realizing that it's a problem. While you might see that code, there are similar circumstances which are less obvious. These are often the results of invisible code introduced by compilers for languages higher than C. Overloaded operators, copy constructors, and destructors can all have much more impact on code than programmers realize. Knowing what kinds of things your language may hide is a good way to avoid these, but some things still slip through. Other things that are easy to miss is how contentious locks, semaphores, mutexes, and other blocking operations are. These are difficult to figure out sometimes. There are also times when you need to demonstrate to someone else where the bottle necks in code are. If your cocky junior programmer weren't your subordinate but rather your boss then the output of a profiler would be something that you could use to combat the cockiness. This is particularly useful when you get "Your code is slow! Fix it!" and you can come back with "This external code/hardware/whatever, which isn't under my control, is what is slow." Another time when using a profiler would be very useful would be if there were disagreement or uncertainty over which of multiple parts of a program were responsible for the different amounts of the slowness. Maybe you need to prioritize the order in which these are addressed. For you or I it may be obvious that a section of code is slower than it has to be, but when comparing two suboptimal sections of code it is very often that eyeballs alone are not enough. There are also times when a profiler can be used to find bugs that would take a lot of stepping in a debugger to locate.
-
Can you share a specific issue that you consider a tricky performance issue? Just curious... ;).
Yes, but before I do, your original email opens up a bigger issue, I think. To demonstrate, let me ask: Does anybody really use a debugger? You see, I think that any real software engineer should be able to write bug-free code and if looking at someone else's code, should be able to identify the bugs in a fairly straight forward process. Pretty silly, right? Of course this is tonge-in-cheek, but the point is that a profiler is a tool that has a place in the engineer's toolbox. By asking the question in a way that belittles the use of the tool, it seems the results of the answers will be biased, or at least the interpretation of the results will be. (Full disclosure: Maybe there are a few who are so good they can optimize their code without a profiler, but I have learned the hard way that I am not one of those - I also used to believe profilers are for the weak.) Engineers use tools. Engineers use data from experiments to test their products and, maybe, improve them. Ignoring a tool doesn't make sense to me. I agree that profilers can be hard to use and produce a lot of noise, but using a lathe is hard, too, until you understand how to get good results from it. A profiler is not the primary tool, to be sure, but there are cases where it can be Indispensable (and has been to me). Here are where I think it makes a lot of sense: 1) Education: How does one get experienced in performance analysis and tuning with C#. And how to we know we are right? Sure, moving the invarient out of the loop make it run faster, but are there other things we could/should have done, as well? Profilers are a great way to learn where the bottlenecks are, especially when working with a new language or in a new environment. One line of code taking 85% of my runtime? How do I know it's that one? (Linq is an easy target, but what about your enum example? How do you know the first time?) I've had experiences similar to yours where I see something obviously bad and let the designer know only to be told "no way it's my problem"; When I show them profiling output proving they are the problem, they start to listen. Data are powerful things! 2) Real-time systems: I think much of the discussion on this thread has been about business-logic type applications. Large databases, searching, etc. But what if you are building a real-time processing system with streaming data in one thread, real-time analysis/processing in another and real-time display in a third (and it's actually much more complicated that that in real life as those t
-
You don't need a profiler to find a problem with this code snippet. :)
string ret = string.Empty;
for (int i=0; (i < someLargeInt); i++) {
ret += AMethodThatReturnsAString (i);
}
return ret;But a profiler can come in mighty handy when trying to identify the bottleneck in complex, old code that no longer seems to scale well. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Always profile. ALWAYS.
string ret = string.Empty;
for (int i=0; (i < someLargeInt); i++) {
ret += AMethodThatReturnsAString (i);
}
return ret;Compilers are smarter than you. This can be compiled into highly optimized code with loop unrolling and expression templates among other optimizations. The rule of thumb is: 1) write simple, clear, expressive code. 2) profile 3) fix hotspots
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
I've done both, and yes, using your noggin to choose a better algorithm wins over using a profiler every time. The profiler can only tell you how to make your bubble sort run faster, it can't tell you to choose to implement a quicksort instead.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
I agree that when analyzing a simple block of code, a profiler is probably overkill. I've used a profiler in the past for projects written by multiple people and that have a lot of other process interactions and data coming in at different rates etc. Profiler stats speak louder and less personally than you going and analyzing other peoples code and giving them the same feedback :-)
-
I agree that when analyzing a simple block of code, a profiler is probably overkill. I've used a profiler in the past for projects written by multiple people and that have a lot of other process interactions and data coming in at different rates etc. Profiler stats speak louder and less personally than you going and analyzing other peoples code and giving them the same feedback :-)
If I was asked to review a co-workers code and he wasn't interested in my feedback unless I produced profiler outputs, charts, stats, graphs and 5 page PDF presentations, I'd consider that co-worker a douche and a waste of time and go work on something else. If my boss came and asked if I had a chance to review Bob's code, I'd simply say "Yup. I located the issue, but Bob wasn't interested in my feedback, so I went back to working on X.". That's not a theoretical "What would you do?" :). I've done that several times over my career and it generally ended very badly. For Bob. I was a newb at a job like on my 2nd or 3rd day and I overhead Bob talking with his boss at the next cubicle about an issue that Bob had been working on for 2 weeks with no success. I was familiar with the issue since I was very strong in that area. So I politely went up to them and said "Excuse me, I couldn't help but hearing about the issue. Not to interupt or anything, but I'm certain your issue could be resolved by doing X as I have run into that issue before and am very familiar with it." Bob pretty much tore me a new one in front of the boss and said that I had no clue what I was talking about as this was my 2nd day on the job and that I should go back to surfing the net or whatever it was he said along those lines. Turned out I was 100% spot on :) and Bob was fired for his unprofessionalism :).
-
Any reason why parametrized SQL code would be slower than a stored procedure? I mean, unless your statement is so big that the network overhead of sending it would be significant, a parametrized statement would have its execution plan cached by the server, same as the stored procedure. Of course it's a lot more interesting to get all the results you need in one statement instead of looping over every row and issuing a SQL statement for every row. Same goes for LDAP.
Additionally, using the stored procedure doesn't eliminate the parameterized SQL code -- so now you have two things that need to be profiled, by two different profilers.
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
SledgeHammer01 wrote:
- don't inline SQL code, use stored procs
If you can inline SQL code, your DBA is an idiot for permitting you to do so. Of course that's the case in 85% (WAG) of the SQL environments out there. The only profiler I use is SQL's and yes, I use it to find slow performance code, but that's because I didn't write most of the code, so I don't know it. I haven't the faintest how to use a profiler to improve performance. To me all it's good for is to find code that could stand improvement.
-
If I was asked to review a co-workers code and he wasn't interested in my feedback unless I produced profiler outputs, charts, stats, graphs and 5 page PDF presentations, I'd consider that co-worker a douche and a waste of time and go work on something else. If my boss came and asked if I had a chance to review Bob's code, I'd simply say "Yup. I located the issue, but Bob wasn't interested in my feedback, so I went back to working on X.". That's not a theoretical "What would you do?" :). I've done that several times over my career and it generally ended very badly. For Bob. I was a newb at a job like on my 2nd or 3rd day and I overhead Bob talking with his boss at the next cubicle about an issue that Bob had been working on for 2 weeks with no success. I was familiar with the issue since I was very strong in that area. So I politely went up to them and said "Excuse me, I couldn't help but hearing about the issue. Not to interupt or anything, but I'm certain your issue could be resolved by doing X as I have run into that issue before and am very familiar with it." Bob pretty much tore me a new one in front of the boss and said that I had no clue what I was talking about as this was my 2nd day on the job and that I should go back to surfing the net or whatever it was he said along those lines. Turned out I was 100% spot on :) and Bob was fired for his unprofessionalism :).
I was surfing code to get a feel for what was being done. I was pleased with the naming conventions because I could tell what was going on just by reading the variable names. Then I read a bug because the code told me exactly what it was doing. Went to my manager, expecting to get my hand slapped for daring to read what was none of my business. Instead I was told it was built per specs. So I asked to see the specs. To my surprise I was given the specs. These were the most exacting specs I'd ever seen. I agreed that the code exactly matched the specs. The manager looked like she thought the subject was closed. Then I said, it's just too bad the specs are asking to have the code do something incorrectly. We ended up in the lab where I said this code should blow up with threading problems at times. The lab tech pipes up, and says they are having problems with code blowing up with threading problems. THEN the manager was willing to look at the math that immediately told me there was a problem. I finally was able to prove that if the maximum thread count was 100 and the step count was 20, the current count was 100, it would ask for 20 more threads, when it was 120, it would ask for 20 more. It would only stop asked for more threads when you reached 121. I can't remember which but setting a + to - or vs versa would have solved the problem or switching the side that added or subtracted the step count would be another way to fix it.
-
I was surfing code to get a feel for what was being done. I was pleased with the naming conventions because I could tell what was going on just by reading the variable names. Then I read a bug because the code told me exactly what it was doing. Went to my manager, expecting to get my hand slapped for daring to read what was none of my business. Instead I was told it was built per specs. So I asked to see the specs. To my surprise I was given the specs. These were the most exacting specs I'd ever seen. I agreed that the code exactly matched the specs. The manager looked like she thought the subject was closed. Then I said, it's just too bad the specs are asking to have the code do something incorrectly. We ended up in the lab where I said this code should blow up with threading problems at times. The lab tech pipes up, and says they are having problems with code blowing up with threading problems. THEN the manager was willing to look at the math that immediately told me there was a problem. I finally was able to prove that if the maximum thread count was 100 and the step count was 20, the current count was 100, it would ask for 20 more threads, when it was 120, it would ask for 20 more. It would only stop asked for more threads when you reached 121. I can't remember which but setting a + to - or vs versa would have solved the problem or switching the side that added or subtracted the step count would be another way to fix it.
Did you also point out to your boss that it doesn't make any sense to have more threads then CPU cores? (or CPU cores x 2 if you turn on hyperthreading). Give or take... If you are banging 100 threads on a 4 core + hyperthreading (8 threads), you'll lose any performance gains from all the context switching :).
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
A profiler is a tool like anything else. It can sometimes expose inefficiencies that you never would have thought of, or other times be useless (e.g. you can't fix what is using most of the CPU time/memory without a significant redesign). A person's assumptions of what is and isn't efficient can also be flawed.. Even with an experienced developer, when it is based on past observations, which could dramatically change with a single new release of your runtime/external libraries/compiler. The same could be said about using a debugger vs. just adding debug logging. With a debugger you may be wasting a lot of time tediously stepping through the code execution, instead of letting it run and simply browsing the debug log to narrow down the problem. But sometimes simple debug output isn't enough, and a debugger is required.
-
I've done both, and yes, using your noggin to choose a better algorithm wins over using a profiler every time. The profiler can only tell you how to make your bubble sort run faster, it can't tell you to choose to implement a quicksort instead.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
The profiler can't tell you how to make your bubble sort faster, only that if you made it faster that would have a major impact on run time (for large data sets). It wouldn't tell you what methods to use to achieve this additional performance, but it would be able to help you understand how and why adding more code sped up the sort (because it executed each piece of code less often).
-
Did you also point out to your boss that it doesn't make any sense to have more threads then CPU cores? (or CPU cores x 2 if you turn on hyperthreading). Give or take... If you are banging 100 threads on a 4 core + hyperthreading (8 threads), you'll lose any performance gains from all the context switching :).
For CPU bound threads this is the case, but if threads are waiting on IO or get to sleep, this is not the case. More threads than cores can sometimes even be a winner for CPU intensive programs if physical memory is the bottle neck under some circumstances (swapping memory to disk is IO that might need to make a thread take a nap). It's nice when you can design for nearly 1-to-1 thread/core relationships, but it's often quicker (in terms of developer time) to mostly write all threads in a style similar to stand alone programs rather than to separate everything into queueable tasklets that don't sleep (they never sleep! but they do run to completion and often schedule a continuation tasklet to handle results of an IO operation or to start up after a given passage of time).