This Blogpost contains some thoughts on learning the sizes arrays, slices or maps are going to reach using Machine Learning (ML) to increase programs\u2019 performances by allocating the necessary memory in advance instead of reallocating every time new elements are appended. <\/p>\n\n\n\n
Well first of all I had to because it is part of the lecture Ultra Largescale Systems (ULS) I attended past winter term. But as an introduction I\u2019ll tell you what made me choose this topic: I started to learn Golang and coming from mainly Java, Python and JavaScript the concept of Arrays with fixed sizes and Slices wrapped around them for convenience was new to me. When I understood that initializing them with the correct capacity is good for performance and memory usage I always tried to so. Until I came to some use case where I could not know the capacity in advance. At almost the same time we talked about \u201cML for Systems<\/a>\u201d in the ULS-lecture. There the power of ML is used to speed up Databases<\/a>, loadbalance Elastic Search Queries<\/a> and other things. So I came up with the idea of ML for programming languages in this case for learning capacities in Golang. By the way I wanted to try out ML in Go, which is said to bring some performance advantages compared to python and is easier to deliver. But neither ML <\/a>in<\/a><\/strong> Go<\/a> (go for ML) nor ML <\/a>on<\/a><\/strong> Go<\/a> is topic of this post, though both appear at some parts. <\/p>\n\n\n\n As explained in various blogposts like here<\/a> and there<\/a>, arrays have fixed sizes in Go. For convenient manipulation anyway they can be wrapped by slices. Thus appending to a slice that reached its capacity needs to create a new slice with a larger underling array, copy the contents of the old slice to the new one and then replace the old one by the new one. This is what the append<\/em> method does. That this process is more time consuming than appending to a slice that has a sufficient capacity can be shown with some very simple code that just appends 100 times to a test slice in a loop. Once the slice is initialized with a capacity of zero and once with 100. For both cases we calculate the durations it takes and compare them. Since those durations can vary for the same kind of initialization we run this 1000 times each and calculate the average duration to get more meaningful results. The averages are calculated by the method printSummary <\/em>which is left out here in order to keep track of things. However the whole code can be found on GitHub<\/a>.<\/p>\n\n\n\nThe goal in more detail<\/h2>\n\n\n\n