[DMS-68] Remove tuple from Map definition

[s-and-witch]

In comparison with #14

Map comparison

	binary_size	generate	max mem	batch_get 50	batch_put 50	batch_remove 50	upgrade
rbtree+100	189_877	225_155	42_540	50_045	135_367	133_686	565_657
persistentmap+100	186_955	229_348	47_144	50_288	140_952	137_667	460_161
persistentmap_baseline+100	187_490	226_832	45_672	49_945	139_070	134_191	512_457
rbtree+1000	189_877	3_118_490	580_948	67_516	181_375	180_396	5_409_805
persistentmap+1000	186_955	3_184_398	641_512	67_943	187_881	186_161	4_360_346
persistentmap_baseline+1000	187_490	3_133_922	612_880	67_416	184_117	181_732	4_878_488
rbtree+10000	189_877	51_301_049	520_428	83_465	224_135	230_257	53_866_589
persistentmap+10000	186_955	49_094_738	400_360	84_056	231_495	237_546	43_379_739
persistentmap_baseline+10000	187_490	51_438_500	520_360	83_365	227_294	231_116	48_561_107
rbtree+100000	189_877	606_914_881	5_200_428	98_012	270_465	276_802	698_928_540
persistentmap+100000	186_955	587_225_673	4_000_360	98_776	279_162	285_517	563_062_175
persistentmap_baseline+100000	187_490	608_157_242	5_200_360	97_912	273_597	277_661	645_876_276
rbtree+1000000	189_877	6_993_676_959	52_000_464	116_417	317_299	330_296	6_988_883_198
persistentmap+1000000	186_955	6_819_487_795	40_000_396	117_370	327_152	340_806	5_630_238_790
persistentmap_baseline+1000000	187_490	7_005_190_168	52_000_396	116_317	320_359	331_196	6_458_379_331

Maximum live heap size

	live mem
persistentmap_100	0
persistentmap_baseline_100	0
rbtree_100	0
persistentmap_1000	0
persistentmap_baseline_1000	0
rbtree_1000	0
persistentmap_10000	400_336
persistentmap_baseline_10000	520_336
rbtree_10000	520_404
persistentmap_100000	4_000_336
persistentmap_baseline_100000	5_200_336
rbtree_100000	5_200_404
persistentmap_1000000	40_000_336
persistentmap_baseline_1000000	52_000_336
rbtree_1000000	52_000_404

Persistent map API

	size	foldLeft	foldRight	mapfilter	map
persistentmap	100	18_397	18_309	98_430	26_043
persistentmap_baseline	100	18_597	18_509	97_613	29_443
persistentmap	1000	152_997	151_945	1_791_712	224_120
persistentmap_baseline	1000	154_997	153_509	1_763_344	258_079
persistentmap	10000	1_501_863	1_483_591	33_511_740	2_204_441
persistentmap_baseline	10000	1_521_863	1_503_632	36_132_684	2_544_359
persistentmap	100000	14_998_975	14_804_493	409_663_616	97_809_311
persistentmap_baseline	100000	15_198_893	15_004_493	434_003_881	132_210_500
persistentmap	1000000	149_997_225	906_008_093	4_820_688_381	978_026_892
persistentmap_baseline	1000000	151_997_225	150_013_513	5_045_781_583	1_322_035_748

[s-and-witch]

Actually, what the hell happened with foldRight on size 1000000?

[GoPavel]

Actually, what the hell happened with foldRight on size 1000000?

benchmarks are deterministic?
Maybe try to run foldRight isolated from others?

[GoPavel]

Why the first table doesn't have comparision with baseline ?

[s-and-witch]

benchmarks are deterministic?

Yes

Maybe try to run foldRight isolated from others?

If I change the order, values change accordingly:

	size	foldRight	foldLeft	mapfilter	map
persistentmap	1000000	148_013_513	907_991_805	4_820_688_381	978_026_892
persistentmap_baseline	1000000	150_013_513	151_997_225	5_045_781_583	1_322_035_748

So, I think this may be GC? But before this patch folds didn't trigger GC.

[s-and-witch]

Why the first table doesn't have comparision with baseline ?

It almost the same as rbtree, so I didn't include it first.

Adding it now, because it still worth to have a full picture in one place.

[GoPavel]

Okay, I think the conclusion from these results is that all general operations like get, put, remove become slower because of the overhead of creating nodes. In the original implementation, we often reuse a pair of (key, value).

The new functionality is a bit faster. So a couple of percentages here against a couple of percentages of general operations.

I would prefer to keep a tuple version (original).

[crusso]

@GoPavel the max memory requirements do seem to go down quite a bit for larger tests (is that like 20%?). Maybe that's worth it?

I wonder if it would be good for the benchmarks tor report allocated_bytes (rather than max-memory). Maybe that would be a better measure of how much allocation is happening.

[GoPavel]

Yeah, I think I missed it. 20% (even 25% I see) sounds significant.
But it's a bit suspicious because persistentmap+1000 consumes more than persistentmap+10000. Probably I was looking at small benchmarks only and overlooked it.
Maybe the effect could be explained by the implementation specifics of the GC or the allocator.
I will rise a discussion in the slack about it

[GoPavel]

On the other hand, probably upgrade speedup shows a real situation with memory consumption. Indeed it is always less for the new version.