You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We expect the simulateTransaction endpoint to be pretty expensive. Namely because:
It accesses the ledger storage (sqlite-based) multiple times
It crosses the Go<->Rust boundary multiple times
We already have a few ideas on how to optimize the code (use a write-through cache for the configuration ledger entries, optimize the data serialization stellar/stellar-rpc#49 etc ...) but we should first have a rough idea about how expensive the endpoint is, and where are the bottlenecks.
To do so, it would be interesting to have a benchmark. Such a benchmark is going to be challenging due to the use of CGO and Go<->Rust interfacing so we need to investigate how to carry it out.
A couple of things to take into account:
Since IO (DB-access) is involved we should probably benchmark the wall-clock time.
Obtaining the CPU bottlenecks of both Go and Rust simultaneously is likely to be pretty hard.
The text was updated successfully, but these errors were encountered:
We expect the
simulateTransaction
endpoint to be pretty expensive. Namely because:We already have a few ideas on how to optimize the code (use a write-through cache for the configuration ledger entries, optimize the data serialization stellar/stellar-rpc#49 etc ...) but we should first have a rough idea about how expensive the endpoint is, and where are the bottlenecks.
To do so, it would be interesting to have a benchmark. Such a benchmark is going to be challenging due to the use of CGO and Go<->Rust interfacing so we need to investigate how to carry it out.
A couple of things to take into account:
The text was updated successfully, but these errors were encountered: