I was writing a function that would ideally be written as function ideal(supervec::Array{Array{Int64,1},1}, vec::Array{Int64,1}) return vcat(supervec[vec]) end But this takes a bit more time than I think is unnecessary julia> using BenchmarkTools julia> @btime ideal([[1],[2]],[1,2]) 23…

You could change it (both) to a while loop, then there is no yellow.

[image] How to prevent type instability in for loops? Performance AFAIU, this “type instability” is harmless. It is a consequence of the iterator interface which returns nothing when the end of the iterator is reached. Note that the line you cited from the @code_warntype o…

Ok, I’ll assume it is ok then. The reason that I asked was when I run ProfileView, this is the only function in the whole code that shows up as red on the resulting graph. So, I guess I should ignore the red bar there and trust this comment and @code_warntype. Thank you!

Interesting, that seems to work, @pixel27 : function whilesimplecount(supervec::Array{Array{Int64,1},1}, vec::Array{Int64,1}) consize = sum(a->length(supervec[a]),vec) con = Array{Int64,1}(undef,consize) counter = 0 j = 0 while j < length(vec) j += 1 b = vec[j] …

[image] swishmas: with no loss in efficiency when tested with @btime but no gain either, I expect

I was seeing differences of about 6ns but that was really just fluctuation based on other activity on the computer. However it sounds like ProfileView is giving false positives, and unfortunately false positives have a habit of hiding true positives.

With the new improved “while” version, the troublesome spots in ProfileView are now gone, so good news there. I think for an individual function call, there is no difference that I can see. For larger inputs and repeated calls to this function, I can see a bit of a difference. Thank you both so mu…

I think this is a really bad idiom, especially since it has no advantage other than removing an inconsequential warning. It spreads the loop control logic over three lines and makes it harder for the reader to parse than the clear, concise, and much less error prone for j=1:length(vec). It screams…

Yeah, agreed–the compiler turns you for loop into a while loop internally anyway, obeying the iteration protocol discussed here: Writing Iterators in Julia 0.7 If you find the while loop easier to write or read, then by all means go for it, but there should be no efficiency advantage in turning all…

I’m not sure if it’s a good idea, but if you change the function signature as below, you get rid of all warnings. Performance is unchanged, of course. BTW, what is intType? function simplecount(supervec::Array{Array{Int64,1},1}, vec::Array{Int64,1}, L=leng…

intType was just trying to copy an HDF5 variable name…it’s just Int64 here

Type stability on Arrays of Arrays in nested for loops?

General Usage Performance

lmiq February 19, 2021, 2:57pm 2

Topic		Replies	Views
Ominous type instability Performance bug , code_warntype , type-stability	10	1312	August 20, 2022
How to prevent type instability in for loops? Performance question	13	1987	October 30, 2019
Code stability with for loop New to Julia	1	1087	November 25, 2019
Why is this simple code type unstable? General Usage	2	314	February 25, 2024
Type instability in a simple function New to Julia code_warntype , type-stability	5	291	November 8, 2025

Type stability on Arrays of Arrays in nested for loops?

Related topics