xdr: update using stellar/xdrgen#68 #4063
Conversation
| @@ -40,7 +40,6 @@ namespace :xdr do | |||
| require "pathname" | |||
| require "xdrgen" | |||
| require 'fileutils' | |||
| FileUtils.rm_f("xdr/xdr_generated.go") | |||
There was a problem hiding this comment.
❗ This looks unrelated and like an unnecessary change. Why is the change needed? I believe this is there to make sure that any xdr_generated.go we have at the end of a generate run is new and no silent error that doesn't result in a new file being written goes undetected.
There was a problem hiding this comment.
It made development unpleasant because my IDE closed the buffer when the file was removed.
There is no compelling reason to remove the file, since it's overwritten.
There was a problem hiding this comment.
Ah interesting. We can solve both problems by replacing the rm with emptying the file. So the file never disappears, but it still behaves as before and is zeroed out?
There was a problem hiding this comment.
I still don't see a compelling reason to reset the file.
| i18n (1.8.10) | ||
| i18n (1.8.11) |
There was a problem hiding this comment.
❗ It looks like you probably ran bundle update xdrgen and it has updated another dependency that is unnecessary. Ruby's bundler will update any dependency it can. Can you change this back to 1.8.10? I think we can avoid updating other dependencies unless we see a need.
There was a problem hiding this comment.
I ran a conservative update, only on xdrgen.
There was a problem hiding this comment.
Even on conservative updates bundler will update all transitive dependencies for the gem you requested be updated.
There was a problem hiding this comment.
I don't see it as a very important side effect.
leighmcculloch
changed the title
|
I was curious and run CPU profiler on Horizon 2.10.0 and master on a small set of latest pubnet ledgers. Highlighted all
|
|
@bartekn is there a benchmark for that? If so, we should run it when optimizing Horizon. If not, I think we should create one. |
|
I think we could have a benchmark for each transaction processor and one for ingestion in general. |
|
I think benchmark makes sense but only with mocked DB to filter it out. I think we can do (in a separate PR) but we are constantly monitoring Horizon metrics so not sure if it's required. |
|
It would be really helpful when working on profiling (not just for monitor how Horizon's performance is going). I think it would be useful even when running against a local DB. |
It improves XDR marshaling performance.
See stellar/xdrgen#68 for details