Jelly performance factors below expectations.
I am not clear on the significance of this statement.
Not significant, just an observation. I've made this statement before, backed-off after finding errors on my code, but after fixing I see performance across the bus that still seem slow. "Seem slow" lacks any scientific backing. I would be curious to hear use cases for PB/Jelly that went beyond the docs.
we say Copyable is the lowest order jelly? The notion that a copy
holder can't ask "is my copy good anymore?" makes it so. Essentially
root says, I'd prefer not to repeat unit of work nor keep track of the
resulting copies, here have the original or resulting copy.
whether your copy is good any more is a PB-level task. Jelly itself is
a separate layer which is about getting the right data to the right
place, not keeping it updated.
Yes PB level, I guess I'm looking for a convention where 1 does not exist. In the renewed interest the comments have tended to overlook copyable, or see copyable as being flushed out.
main issue is a copy-holder calling for a copy to determine is the copy
is good anymore. I know, see cacheable but it's problematic.
"problematic" is passive voice :-). What are the problems?
Only parroting what I've read on cacheable, haven't delved into yet.
At this point I'm unsure of what jelly actually does well.
Jelly's main claim to fame is "it's better than pickle". But with all
this renewed interest in PB perhaps we'll get pre-deserialization schema
enforcement and type checking, and then it will have some real