tendermint

291 MiB

Tree: 15878dc80c

Author	SHA1	Message	Date
Sean Braithwaite	671c5c9b84	crypto: Proof of Concept for iterative version of SimpleHashFromByteSlices (#2611 ) (#3530 ) (#2611) had suggested that an iterative version of SimpleHashFromByteSlice would be faster, presumably because we can envision some overhead accumulating from stack frames and function calls. Additionally, a recursive algorithm risks hitting the stack limit and causing a stack overflow should the tree be too large. Provided here is an iterative alternative, a simple test to assert correctness and a benchmark. On the performance side, there appears to be no overall difference: ``` BenchmarkSimpleHashAlternatives/recursive-4 20000 77677 ns/op BenchmarkSimpleHashAlternatives/iterative-4 20000 76802 ns/op ``` On the surface it might seem that the additional overhead is due to the different allocation patterns of the implementations. The recursive version uses a single `[][]byte` slices which it then re-slices at each level of the tree. The iterative version reproduces `[][]byte` once within the function and then rewrites sub-slices of that array at each level of the tree. Eexperimenting by modifying the code to simply calculate the hash and not store the result show little to no difference in performance. These preliminary results suggest: 1. The performance of the current implementation is pretty good 2. Go has low overhead for recursive functions 3. The performance of the SimpleHashFromByteSlice routine is dominated by the actual hashing of data Although this work is in no way exhaustive, point #3 suggests that optimizations of this routine would need to take an alternative approach to make significant improvements on the current performance. Finally, considering that the recursive implementation is easier to read, it might not be worthwhile to switch to a less intuitive implementation for so little benefit. * re-add slice re-writing * [crypto] Document SimpleHashFromByteSlicesIterative	6 years ago
Dev Ojha	55d7238708	Add comment to simple_merkle get_split_point (#3136 ) * Add comment to simple_merkle get_split_point * fix grammar error	6 years ago
Dev Ojha	ec53ce359b	Simple merkle rfc compatibility (#2713 ) * Begin simple merkle compatibility PR * Fix query_test * Use trillian test vectors * Change the split point per RFC 6962 * update spec * refactor innerhash to match spec * Update changelog * Address @liamsi's comments * Write the comment requested by @liamsi	6 years ago
Dev Ojha	124d0db1e0	Make txs and evidencelist use merkle.SimpleHashFromBytes to create hash (#2635 ) This is a performance regression, but will also spare the types directory from knowing about RFC 6962, which is a more correct abstraction. For txs this performance hit will be fixed soon with #2603. For evidence, the performance impact is negligible due to it being capped at a small number.	6 years ago
Dev Ojha	1b51cf3f46	Remove unnecessary layer of indirection / unnecessary allocation of hashes (#2620 )	6 years ago
Dev Ojha	12fa9d1cab	crypto/merkle: Remove byter in favor of plain byte slices (#2595 ) * crypto/merkle: Remove byter in favor of plain byte slices This PR is fully backwards compatible in terms of function output! (The Go API differs though) The only test case changes was to refactor it to be table driven. * Update godocs per review comments	6 years ago
Zach Ramsay	44dad6d70b	Revert "detele everything" This reverts commit `d02c5d1e30`.	6 years ago
Zach Ramsay	d02c5d1e30	detele everything	6 years ago
Anton Kaliaev	61c5791fa3	revert back to Jae's original payload size limit except now we calculate the max size using the maxPacketMsgSize() function, which frees developers from having to know amino encoding details. plus, 10 additional bytes are added to leave the room for amino upgrades (both making it more efficient / less efficient)	6 years ago
Liamsi	c96b27136f	remove go-crypto from go-crypto: use tendermint/crypto :-)	6 years ago

9 Commits (15878dc80ccec03f32086415fbfea4b66164150c)