Re: [racket-users] Speeding up the conversion of flvectors to string

2021-06-29 Thread Jonathan Simpson
On Monday, June 28, 2021 at 10:25:36 PM UTC-4 Sam Tobin-Hochstadt wrote: > On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson wrote: > > > > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: > >> > >> Replacing ` (~r x #:precision 1)` with `(number->string x)` and ditto > for

Re: [racket-users] Speeding up the conversion of flvectors to string

2021-06-29 Thread Robby Findler
A little more information about these things. I'd say that there are two obstacles to having the racket/contract library actually be the source of the contract checks in all functions exported by the racket language/library: 1) dependency layering. The racket/contract library is really a

Re: [racket-users] Speeding up the conversion of flvectors to string

2021-06-29 Thread Sam Tobin-Hochstadt
On Tue, Jun 29, 2021 at 12:04 PM Jonathan Simpson wrote: > > On Monday, June 28, 2021 at 10:25:36 PM UTC-4 Sam Tobin-Hochstadt wrote: >> >> On Mon, Jun 28, 2021 at 9:46 PM Jonathan Simpson wrote: >> > >> > On Sunday, June 27, 2021 at 10:29:55 AM UTC-4 Robby Findler wrote: >> >> >> >> Replacing `

Re: [racket-users] Speeding up the conversion of flvectors to string

2021-06-29 Thread Jonathan Simpson
Thanks Sam, Robby. Your explanations make perfect sense. I was conflating contract exceptions with the contract library. I had just assumed they were one and the same. Avoiding the contract library for performance reasons in some cases also seems quite reasonable to me. Thanks again! --

Re: [racket-users] Speeding up the conversion of flvectors to string

2021-06-29 Thread Stefan Schwarzer
On 2021-06-28 21:18, Alessandro Motta wrote:> One thing that is still puzzling / worrying me: I completely failed to > identify the actual bottleneck when profiling the code. > > Did I simply misinterpret the profiling output / flame graph? Or is the > problem rather that memory allocations and