# Processus stop for large array of images

**URL:** <https://discourse.julialang.org/t/processus-stop-for-large-array-of-images/85921>\
**Category:** Performance\
**Tags:** array, memory-allocation\
**Created:** [August 18, 2022, 12:27pm UTC](https://discourse.julialang.org/t/processus-stop-for-large-array-of-images/85921 "2022-08-18T12:27:46Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![musard0](https://avatars.discourse-cdn.com/v4/letter/m/258eb7/32.png) [@musard0](https://discourse.julialang.org/u/musard0)\
**Post date:** [August 18, 2022, 12:27pm UTC](https://discourse.julialang.org/t/processus-stop-for-large-array-of-images/85921/1 "2022-08-18T12:27:47Z")

</div>

Hello, here is my code :

```julia
using Images
function listOfImg(img::Array{Gray{Normed{UInt8,8}},2})
	lengthImgSplit = 1000
	nbImgToSave = 3000
	imgSplit = similar(img, size(img, 1), lengthImgSplit)
	listOfImg = Array{typeof(imgSplit),1}(undef, nbImgToSave)
	for i in 1:nbImgToSave
		listOfImg[i] = img[:, i:(i+lengthImgSplit)]
	end
	return listOfImg
end

```

img = 338×45526 Array{Gray{N0f8},2} with eltype Gray{Normed{UInt8,8}}  
My problem is that my computer stopped when nbImgToSave \> 3000  
When nbImgToSave = 1000, the processus finish in 1.1s, with 2000, it is 2.1s (29.71 k allocations: 647.112 MiB, 18.16% gc time), with 3000, 12.5s (31.71 k allocations: 1.892 GiB, 23.11% gc time) and with 4000 my computer stopped … I think, one part of the problem is because i’ve an old computer (2G of Ram and a SSD of 16G with only 3G free). But i wish to split the entire image (so nbImgToSave ~ 44000) and i want to know if there is a way for this with my material ?

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [August 18, 2022, 1:45pm UTC](https://discourse.julialang.org/t/processus-stop-for-large-array-of-images/85921/2 "2022-08-18T13:45:27Z")

</div>

With a 338x45526 `img`, and `nbImgToSave = 3000` and `lengthImgSplit = 1000`, then each element of `listOfImg` is an array of size `338x1000`, and you have 3000 of them. That’s about 1Gb of memory just to hold all those split images, so it’s no wonder your computer is having trouble.

I think the fundamental problem is that you are _copying_ the 338x1000 pieces of `img` each time you do `img[:, i:(1:lengthImgSplit)]`. But there may not be any need to do that–as long as you don’t need to modify the elements of `listOfImg` separately, you can instead just tell Julia to record a _view_ of each part of the image. That doesn’t require copying any data at all, and it should decrease your memory usage by almost 100%.

For example:

```julia
function listOfImg2(img::Array{Gray{Normed{UInt8,8}},2})
	lengthImgSplit = 1000
	nbImgToSave = 3000
	listOfImg = [@view(img[:, i:(i + lengthImgSplit)]) for i in 1:nbImgToSave]
	return listOfImg
end

```

Let’s compare performance:

```julia
julia> using BenchmarkTools;

julia> img = rand(Gray{N0f8}, 338, 45526);

julia> @btime listOfImg($img)
  581.718 ms (6004 allocations: 968.56 MiB)

julia> @btime listOfImg2($img);
  11.092 μs (2 allocations: 140.67 KiB)

```

`listOfImg2` is more than 50,000 times faster, and it uses about 7,000 times less memory!

The only thing to be aware of is that with `listOfImg2`, each element of the result points to the _same_ memory inside the original `img`. So if you mutate `img` or mutate any of the elements in the list of slices, then they will all change.

---

<div class="post-metadata">

**Author:** ![musard0](https://avatars.discourse-cdn.com/v4/letter/m/258eb7/32.png) [@musard0](https://discourse.julialang.org/u/musard0)\
**Post date:** [August 18, 2022, 5:29pm UTC](https://discourse.julialang.org/t/processus-stop-for-large-array-of-images/85921/3 "2022-08-18T17:29:14Z")

</div>

Thanks a lot, it solves my problem. I will study more deeply the way julia is running so i can benefit of its performances … You are right, the memory usage decrease by almost 100% 😀