Stack vs queue vs array how to#
Probably one of the most important is how to store data. How we are going to store our data, how we are going to deal with state logic, how we should handle authentication, etc.
Stack vs queue vs array code#
Anyone looking at our code and seeing a “Queue” type is going to know exactly what it’s doing.Learn about two important data structures-stack and queue-and how to implement them in JavaScript.Įvery time we are developing a new application, there are certain topics that we should think through first in order to achieve our goal and have a nice result. We are actually using the correct data type for the correct use. We aren’t doing some “hack” to squeeze juice out of it. Not only is performance that much better using a queue, but it’s actually the right data type anyway. Now is this over thinking everything? Maybe. And the larger the queue, the more performance we can squeeze out of not using a list. So swapping a queue, even at a relatively small size of 100 items, is 5x faster. We also have different sizes of queues to just compare how the size of the queue may affect the performance.Īnd the results? | Method | size | Mean | Ratio | We simply insert X amount of items, and then dequeue until we are done. Well, there’s an easy way to solve this using BenchmarkDotNet. But how much faster would Queue actually be? What if we only have a hundred items? Is there actually any noticeable difference? The problem is we are trying to use a List type for a job that is clearly suited to Queue. Just touching on number 3, we could instead change the remove line to be : workingList.RemoveAt(0) Our removing code requires us to compare object references within the list rather than remove it by index (Although this is the least of our problems).This actually means that the list itself all shifts up 1 place, a much larger operation than I first thought. We remove the item from the front of the list.This is probably pretty fast, but we do this as an additional check rather than just trying to “pop” an item immediately. We have a call to “Any()” to check if we have items.Just how much performance can be squeezed out of this we will certainly delve into, but let’s look at the problems of this code in a nutshell. Immediately looking at this code I realized it’s basically a makeshift queue built ontop of a list type, but with some clear performance issues in mind. And then later on we have a loop that looks like so :
Arrays, queues, stacks and pipelines are all pretty much non-existent in any sort of business logic code I write, and as we’re about to find out, maybe that’s to my own detriment.īack to the code I was talking about, it looked something like this : //Somewhere in the code we add a bunch of items to the working list. Maybe this sounds like a real rookie mistake, but there is definitely a common theme among C# developers (myself included), that use List as basically the catch all for any sort of collection. And you would be right, it basically is a queue but written using a List object.
Now even me describing this code now you’re probably thinking. I was recently investigating a piece of non-performant code that essentially boiled down to a loop that pulled items off a “working list”, and when the work was done, removed it from the list.
0 kommentar(er)
