Hello Andreas,
consider iterating over a Dict{Symbol,Int64}:
d = Dict(:foo => 42, :bar => 77)
for x in d println("$(typeof(x)), $(isbits(x))") end
During iteration, a lot of stack allocated "Pair{Symbol,Int64}" objects are
created. That is very bad for performance.
immutable CategorizedPoint
x::Float64
y::Float64
category::Symbol
end
Also, consider a (hypothetical) data type for categorized points (with a
finite number of categories - but extensible, so that Symbol is a better
fit than using an enum):
immutable CategorizedPoint
x::Float64
y::Float64
category::Symbol
end
I would definitely want this to be a bits-type, and not have every instance
heap-allocated.
Cheers,
Oliver
On Wednesday, August 17, 2016 at 11:44:13 AM UTC+2, Andreas Lobinger wrote:
>
> Hello colleague,
>
> On Wednesday, August 17, 2016 at 11:12:51 AM UTC+2, Oliver Schulz wrote:
>>
>> Sure - I was assuming that as Symbol (as an interned string) is
>> basically just a pointer. So comparisons are O(1), etc. What I'd like to
>> understand is, why can't it be a bitstype? Currently, it's not, so Symbol
>> cannot be used in a lightweight (i.e. stack-allocated) immutable type. I
>> assume there's a good reason for it, I just want to understand why.
>>
>
> Could you make an example how you would like to use Symbol in lightweight
> types?
>
>
