Conversation
larskuhtz
changed the title
|
A somewhat open question is the amount of inlining for the aeson instances. This affects compilation times. I think, the aeson package itself removed all inlining in recent version, to reduce compilation times. On the other hand inlining can make a big difference in runtime performance. The current version of the PR does not inline some larger instances in particular in cyclic data type dependencies. |
| instance ToJSON a => ToJSON (SigData a) where | ||
| toJSON (SigData h s c) = object $ concat | ||
| [ ["hash" .= h] | ||
| , ["sigs" .= object (map (\(k,ms) -> (unPublicKeyHex k, maybe Null (toJSON . _usSig) ms)) s)] |
There was a problem hiding this comment.
This instance seems to be in conflict with the comment above:
, _sigDataSigs :: [(PublicKeyHex, Maybe UserSig)]
-- ^ This is not a map because the order must be the same as the signers inside the command.Should that be fixed? Would it break backwards compatibility?
src/Pact/Types/SigData.hs
Outdated
| , "sigs" .= HM.fromList (bimap unPublicKeyHex (fmap _usSig) <$> _sigDataSigs o) | ||
| -- FIXME fix order independently of hashable package |
There was a problem hiding this comment.
Use LegacyHashMap for backward compatible behavior. Use list for pairs for behavior that complies with the comment on the _sigDataSigs constructor field.
@jmcardon what would be the correct behavior here?
There was a problem hiding this comment.
I think this falls under ApiReq (maybe grep to be sure) which means it doesn't show up on blockchain, thus low-stakes what we do here.
sirlensalot
left a comment
sirlensalot
left a comment
There was a problem hiding this comment.
Great work! Main themes in review:
-
promote
LegacyValuetoJsonValue(and move to aTypesfile), see discussion on type. -
Can we consider a
Genericsolution that somehow leverages aJsonPropertiesvalue? Would cut code down. -
We have enough "elide on
Foldable.null" cases to merit support a laMaybesupport, let's consider generalizing. -
Are we removing
enableToJSONin this PR? -
Consider rename also for
LegacyHashMapalthough here it really is legacy ... at a minimumLegacyHashedis a good name.
| @@ -46,6 +46,7 @@ import Data.ByteString (ByteString) | |||
| import qualified Data.ByteString.Lazy.Char8 as BSL | |||
There was a problem hiding this comment.
While this is good work, we should consider not migrating this just to make the PR smaller -- ApiReq never results in code on the blockchain, and while it's perhaps nice for Chainweaver and tools, we can't guarantee a particular coding order in JS clients etc.
src/Pact/Utils/Json.hs
Outdated
| -- -------------------------------------------------------------------------- -- | ||
| -- | ||
|
|
||
| newtype LegacyValue = LegacyValue { getLegacyValue :: Value } |
There was a problem hiding this comment.
I agree with this. Legacy makes it seem like an artifact of the past that will soon be deprecated.
|
This has been merged via #1242 |
7 participants
Overview
Backward & forward compatibility
The dependencies with the greatest consequences for preserving legacy behavior are JSON encoding and text processing.
JSON
Modern
aeson(>= 2.0) uses a different algorithm for sorting the fields of objects than our older pinned version ofaeson. A large part of this PR is makingpactuse thepact-jsonlibrary for all serialization and deserialization.pact-jsonfocuses on explicit, predictable encoding over programmer convenience, and it provides helpers for encoding into the legacy format.Source parsing
Modern versions of
text,trifectaandattoparsecbring various API changes and changes to internal logic. In particular the handling of unicode character counting changed whentextmoved from utf-16 to utf-8 for its internal representation. This PR introduces an abstracted parser that shims the new behavior to produce character counts compatible with the older versions.Performance regressions
Recent runs of the pact benchmarks are available for this branch (ghc-9.6.1) and master (ghc-8.10.7). Most benchmarks are slightly faster in the newer version. The largest benchmark, which compiles and runs a small currency-exchange contract, goes from 3.7 to 1.7 seconds uncached, 0.22 to 0.18 seconds cached. Performance is worse for the new branch when using an in-memory database. These results need to be replicated on other machines.
TODO: check the time required to run replay on this branch, compared to
master.ghc-9.6.1:
ghc-8.10.7:
