I have a situation where I’m processing rowwise data from a JuliaDB table in a reducer. I’m having trouble with type stability, because my function looks like: function (row, col) value = row[col] ...do things with value... end This is not surprising because Julia doesn’t know at compile tim…

[image] mattwigway: (if you enclose the whole thing in a function, the allocations go away for both functions, but only because Julia can infer the value and type of t at compile time - which doesn’t solve my overall problem) That sounds suspicious to me, because it would be the first thing t…

You’re right, that was a bad example. Here’s a better one. The critical thing is that which key is to be extracted from the NamedTuple is not known at compile time, and that the NamedTuple has values that are not all the same type. Here’s a better example, with the key read from the command-line arg…

[image] mattwigway: I explicitly tell Julia that it’s going to be an Int64 it’s just a type assertion, and as you’ve seen, the allocation happens before the assertion (during the getindex). [image]

Maybe this helps: using BenchmarkTools access(x, i) = x[i] function test1(symbol) t = (abc=1, tba=2.0, cd="jgds") access(t, symbol) end dispatch(::Val{:abc}, x) = access(x, :abc) dispatch(::Val{:tba}, x) = access(x, :tab) dispatch(::Val{:tba}, x) = access(x, :cd) function test2(symbol)…

I think the allocation that you observe with unstable is a benchmarking artifact. If you use BenchmarkTools, it goes away: using BenchmarkTools t = (abc=1, tba=2.0) unstable(x, i) = x[i] julia> @btime unstable($t, :abc); 0.039 ns (0 allocations: 0 bytes) Of course now we see another benchmarkin…

[image] mattwigway: the NamedTuple has values that are not all the same type. I intervene to ask a question that makes me understand something about how these mechanisms work, rather than suggesting some kind of solution. If your situation allows it, wouldn’t it be useful to change and use c…

I am running into what I think is the same underlying issue (though possibly not, I am happy to start a different thread if that is appropriate). When I try to access an arbitrary value in a NamedTuple, I see some allocations if the value is not defined within the function. For example: using Benc…

You’re not doing anything wrong, in fact you wrote a test perfectly avoiding global variable artifacts on your first try. And yes, you’re on the right thread. Julia generally specializes a call on the types of the called object and the arguments. For example, f(1, 1.5) specializes on (typeof(f), In…

How to avoid allocations when reading arbitrary keys from a NamedTuple?

General Usage Performance

jling November 20, 2021, 2:39am 4

it’s just a type assertion, and as you’ve seen, the allocation happens before the assertion (during the getindex).

Topic		Replies	Views
Allocations from selecting fields of a named tuple Performance question , namedtuple	4	371	December 28, 2023
Reduce allocations when extracting values from NamedTuples Performance question , namedtuple	12	513	January 12, 2024
Named Tuple Constructor type unstable? General Usage	7	1509	April 24, 2019
Advice to make getfield(::NamedTuple, ::Symbol) typestable Performance	19	1124	March 25, 2022
How to get a tuple's field using a runtime index in a type stable way? General Usage	24	814	March 16, 2024

How to avoid allocations when reading arbitrary keys from a NamedTuple?

Related topics