you can make it into a defp and name the function differently and you will not need to run the is_binary(v) check since it was checked in the previous call.
eksperimental
0
amnu3387
Yeap, but then only works for atom keyed maps - that version was to allow binary keys too - but good pointers
0
eksperimental
Here’s my improved version built on top of @amnu3387 's version.
defmodule Sanitizer do
@spec parse_map_int_fields(map) :: map
def parse_map_int_fields(map) when is_map(map) do
Enum.reduce(map, [], fn
{k, v}, acc when is_atom(k) and is_binary(v) ->
[{k, transform_v(Atom.to_string(k), v)} | acc]
k_v, acc ->
[k_v | acc]
end)
|> :maps.from_list()
end
defp transform_v(<<"int_", _>>, v) do
case Integer.parse(v) do
{v_int, ""} -> v_int
_ -> nil
end
end
defp transform_v(_k_string, v) do
v
end
end
I use a list to build the new map, and then convert it into a map. Could be faster or not depending on how many items get updated from the original map.
Check out this new test_map. If you really want to check on a full representation of an integer, you need to pattern match on the remainder, to be ""
test_map = %{
int_a: "1",
int_b: "not_a_int!",
int_c: "1.2",
int_d: "1x",
int_x: 42,
str_a: "This is a string field",
str_b: "Another string field",
fl_a: 0.0,
}
Sanitizer.parse_map_int_fields(test_map)
iex(5)> Sanitizer.parse_map_int_fields(test_map)
%{
fl_a: 0.0,
int_a: 1,
int_b: nil,
int_c: nil,
int_d: nil,
int_x: 42,
str_a: "This is a string field",
str_b: "Another string field"
}
0
rmoretto
I agree with you that to be more precise with the parsing the "" remainder should be match, but in my use case is better that any integer is saved than none.
I have run the benchmark with the code that you shared, only changing the line {v_int, ""} to {v_int, _} to match the other functions, here are the results:
Name ips average deviation median 99th %
mnussbaumer_response 960.24 K 1.04 μs ±2517.65% 0.94 μs 1.80 μs
gregvaughn_response 868.02 K 1.15 μs ±1919.57% 1.03 μs 2.04 μs
kokolegorille_response 827.66 K 1.21 μs ±2517.58% 1.09 μs 1.65 μs
ericgray_response 724.15 K 1.38 μs ±1604.94% 1.26 μs 2.50 μs
chungwong_response 656.80 K 1.52 μs ±1600.17% 1.38 μs 2.71 μs
parse_map_int_fields 623.51 K 1.60 μs ±1424.02% 1.45 μs 2.52 μs
eksperimental_response 612.94 K 1.63 μs ±1509.09% 1.47 μs 2.92 μs
Comparison:
mnussbaumer_response 960.24 K
gregvaughn_response 868.02 K - 1.11x slower +0.111 μs
kokolegorille_response 827.66 K - 1.16x slower +0.167 μs
ericgray_response 724.15 K - 1.33x slower +0.34 μs
chungwong_response 656.80 K - 1.46x slower +0.48 μs
parse_map_int_fields 623.51 K - 1.54x slower +0.56 μs
eksperimental_response 612.94 K - 1.57x slower +0.59 μs
I guess that the :maps.from_list() is too expensive to be worth in this specific case?
1
dimitarvp
Naive solution on a first try:
defmodule IntMapSanitizer do
@test_map_1 %{
greet: "Hirrow",
int_a: "17",
int_b: "gibberish",
int_c: "428",
farewell: "Aufwiedersehen"
}
defp is_int_name?(k) when is_atom(k) do
k
|> Atom.to_string()
|> String.starts_with?("int_")
end
defp should_keep?(v) when is_nil(v) or is_integer(v), do: false
defp should_keep?(_), do: true
defp parse_to_int_or_nil(v) do
case Integer.parse(v) do
:error ->
nil
{parsed, _} ->
parsed
end
end
def sanitize(%{} = map) do
for {k, v} <- map, is_int_name?(k), should_keep?(v), reduce: map do
acc -> Map.update(acc, k, nil, &parse_to_int_or_nil(&1))
end
end
def test1() do
sanitize(@test_map_1)
end
end
Try in iex:
iex(1)> IntMapSanitizer.test1()
%{
farewell: "Aufwiedersehen",
greet: "Hirrow",
int_a: 17,
int_b: nil,
int_c: 428
}
Haven’t measured but for comprehensions with filters and the reduce option have always been fairly fast in my experience.
Maybe if you make a public GitHub repo then we can make a benchmarking arena. 
1