Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
On Thursday, September 17, 2020 at 7:54:23 AM UTC+8 gneuner2 wrote: > > That's true - Windows tries IPv6 first Windows does not try IPv6 first. Client applications that call `getaddrinfo` with `AF_UNSPEC` , ask for both IPv4 and IPv6 addresses when resolving names. When that happens, the resolver library (maybe on Windows only?) returns a list of IP addresses for that name, but puts IPv6 addresses first. The code than tries to connect to addresses in the order they are returned, meaning they try IPv6 first. If client applications would specify AF_INET instead for their `getaddrinfo` call, they would only get IPv4 addresses, but my understanding is that AF_UNSPEC is the recommended flag for new applications, and I think Racket is using it. I am not sure how things work on Linux with respect to address resolution, but on my windows machine, "ping localhost" receives responses from "::1" while on my RaspberryPi it receives responses from "127.0.0.1", even though I have the "::1" address for localhost as well. Strangely, it even responds from 127.0.0.1 when I ping "ip6-localhost" which is only listed as "::1" in my /etc/hosts file. Alex. > - but it isn't the whole story > here. If IPv6 were the only cause, then disabling IPv6 should fix the > problem ... but it doesn't always fix the problem. On some Windows > machines, name resolution by the local DNS client is just painfully slow > [and no one knows exactly why]. > > Certainly Stephen should try either binding the server to ::1 or > disabling IPv6 altogether ... but it's possible that neither of these > options may solve his problem. > > George > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5c5e6d88-cbf0-4c15-b73a-9f9c4958b42an%40googlegroups.com.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
On 9/16/2020 5:59 PM, Alex Harsanyi wrote: On Windows at least, "localhost" resolves to two IP addresses (in this order): "::1" (IPv6) and "127.0.0.1". The Racket `tcp-connect` function will try the fist one first, and since you probably don't bind your web server to the IPv6 address, the connection times out, than `tcp-connect` tries the IPv4 one and succeeds. This is why using "localhost" is slower than using "127.0.0.1". I know this because I have been caught by it as well :-) My solution was to learn IpV6 and start my server on IPv6 :-) Perhaps curl and Chrome go straight for the IPv4 address. As a test, try starting your web server on an IPv6 address (::1) and see if things improve. Alex. That's true - Windows tries IPv6 first - but it isn't the whole story here. If IPv6 were the only cause, then disabling IPv6 should fix the problem ... but it doesn't always fix the problem. On some Windows machines, name resolution by the local DNS client is just painfully slow [and no one knows exactly why]. Certainly Stephen should try either binding the server to ::1 or disabling IPv6 altogether ... but it's possible that neither of these options may solve his problem. George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/ba034951-9271-03fa-6d3d-e98879ba7792%40comcast.net.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
On Windows at least, "localhost" resolves to two IP addresses (in this order): "::1" (IPv6) and "127.0.0.1". The Racket `tcp-connect` function will try the fist one first, and since you probably don't bind your web server to the IPv6 address, the connection times out, than `tcp-connect` tries the IPv4 one and succeeds. This is why using "localhost" is slower than using "127.0.0.1". I know this because I have been caught by it as well :-) My solution was to learn IpV6 and start my server on IPv6 :-) Perhaps curl and Chrome go straight for the IPv4 address. As a test, try starting your web server on an IPv6 address (::1) and see if things improve. Alex. On Wednesday, September 16, 2020 at 11:14:29 PM UTC+8 Stephen Foster wrote: > Thanks everyone. We resolved the issue over on the http-easy package: > https://github.com/Bogdanp/racket-http-easy/issues/6 > > I'll summarize for the curious: > > Turns out it's largely a "my system thing": requests to "localhost" are > slow, but 127.0.0.1 are fast. On Chrome and curl, both were fast, which is > why I assumed the slowdown was in some Racket package. It's more likely a > DNS issue. (I have to use an unfamiliar Windows machine for game > development; there's probably something misconfigured about the DNS.) > > In any event, my original problem is solved: I can use Racket's packages > and send requests to 127.0.0.1, and the spellcasting experience in > CodeSpells is super-snappy now. > > Thanks again, everyone! And thanks Bogdan -- both for the help, and for > the http-easy package. :) > > On Mon, Sep 14, 2020 at 3:42 PM Sam Phillips wrote: > >> Hi Stephen, >> >> I ran this small benchmark against a remote web server, and was >> definitely getting better response using the http-easy module. >> >> https://gist.github.com/samdphillips/32763ebd0d938678c2972b1dd8ee5778 >> >> $ racket -e '(require (submod "http-perf.rkt" curl))' >> cpu time: 768 real time: 35299 gc time: 0 >> >> $ racket -e '(require (submod "http-perf.rkt" http-easy))' >> cpu time: 1810 real time: 17316 gc time: 70 >> >> On Mon, Sep 14, 2020 at 12:57 PM Stephen Foster >> wrote: >> > >> > Finally circling back to this issue. I've disabled debugging in >> DrRacket and also done a test outside of DrRacket. It's still slow. :( >> > >> > I also tried the newer HTTP client: >> https://docs.racket-lang.org/http-easy/index.html. Like the others, it >> is also slow. >> > >> > I'll do some more digging. I'm currently trying to figure out if this >> is a "just me" / "just my system" problem. So... I'd be grateful if anyone >> who has written code that sends HTTP requests from Racket could chime in >> with: 1) I can confirm that sending HTTP requests from Racket has always >> been fast for me, or 2) I too have noticed Racket HTTP requests are slow. >> > >> > (Note that by "slow", I mean: takes noticeably longer than curl.) >> > >> > >> > >> > On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri wrote: >> >> >> >> Hi Stephen, >> >> >> >> Your video shows you running this code in DrRacket with debugging >> >> enabled. That usually affects performance. Have you made measurements >> >> when running this code outside of DrRacket? >> >> >> >> - Jon >> >> >> >> >> >> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster >> wrote: >> >> > >> >> > I'm considering using Racket to remake my 3D game CodeSpells. I'm >> using http requests to have Unreal Engine and Racket talk to each other. >> >> > >> >> > When I use the http/request library, Racket fires off its GET >> request much slower than if it were to do a system call to curl. (Same is >> true if I use simple-http, which makes me think the problem might be a deep >> one.) >> >> > >> >> > Here's a video to demo the issue. Notice how, with curl, the >> experience is playable, whereas with the Racket function, there's way too >> much time between the spell landing and the effect occurring: >> >> > >> >> > https://youtu.be/jTqUFVlfBFA >> >> > >> >> > Obviously, I'd like to do things in a Rackety way. But I'm not >> above doing things the silly way. I'd just be grumpy about it. >> >> > >> >> > Any ideas? >> >> > >> >> > >> >> > >> >> > -- >> >> > You received this message because you are subscribed to the Google >> Groups "Racket Users" group. >> >> > To unsubscribe from this group and stop receiving emails from it, >> send an email to racket-users...@googlegroups.com. >> >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com >> . >> > >> > >> > >> > -- >> > >> > >> > Stephen Foster >> > ThoughtSTEM Co-Founder >> > 318-792-2035 <(318)%20792-2035> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "Racket Users" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to racket-users...@googlegroups.com. >> > To view this discussion on the web
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
Thanks everyone. We resolved the issue over on the http-easy package: https://github.com/Bogdanp/racket-http-easy/issues/6 I'll summarize for the curious: Turns out it's largely a "my system thing": requests to "localhost" are slow, but 127.0.0.1 are fast. On Chrome and curl, both were fast, which is why I assumed the slowdown was in some Racket package. It's more likely a DNS issue. (I have to use an unfamiliar Windows machine for game development; there's probably something misconfigured about the DNS.) In any event, my original problem is solved: I can use Racket's packages and send requests to 127.0.0.1, and the spellcasting experience in CodeSpells is super-snappy now. Thanks again, everyone! And thanks Bogdan -- both for the help, and for the http-easy package. :) On Mon, Sep 14, 2020 at 3:42 PM Sam Phillips wrote: > Hi Stephen, > > I ran this small benchmark against a remote web server, and was > definitely getting better response using the http-easy module. > > https://gist.github.com/samdphillips/32763ebd0d938678c2972b1dd8ee5778 > > $ racket -e '(require (submod "http-perf.rkt" curl))' > cpu time: 768 real time: 35299 gc time: 0 > > $ racket -e '(require (submod "http-perf.rkt" http-easy))' > cpu time: 1810 real time: 17316 gc time: 70 > > On Mon, Sep 14, 2020 at 12:57 PM Stephen Foster > wrote: > > > > Finally circling back to this issue. I've disabled debugging in > DrRacket and also done a test outside of DrRacket. It's still slow. :( > > > > I also tried the newer HTTP client: > https://docs.racket-lang.org/http-easy/index.html. Like the others, it > is also slow. > > > > I'll do some more digging. I'm currently trying to figure out if this > is a "just me" / "just my system" problem. So... I'd be grateful if anyone > who has written code that sends HTTP requests from Racket could chime in > with: 1) I can confirm that sending HTTP requests from Racket has always > been fast for me, or 2) I too have noticed Racket HTTP requests are slow. > > > > (Note that by "slow", I mean: takes noticeably longer than curl.) > > > > > > > > On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri wrote: > >> > >> Hi Stephen, > >> > >> Your video shows you running this code in DrRacket with debugging > >> enabled. That usually affects performance. Have you made measurements > >> when running this code outside of DrRacket? > >> > >> - Jon > >> > >> > >> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster > wrote: > >> > > >> > I'm considering using Racket to remake my 3D game CodeSpells. I'm > using http requests to have Unreal Engine and Racket talk to each other. > >> > > >> > When I use the http/request library, Racket fires off its GET request > much slower than if it were to do a system call to curl. (Same is true if > I use simple-http, which makes me think the problem might be a deep one.) > >> > > >> > Here's a video to demo the issue. Notice how, with curl, the > experience is playable, whereas with the Racket function, there's way too > much time between the spell landing and the effect occurring: > >> > > >> > https://youtu.be/jTqUFVlfBFA > >> > > >> > Obviously, I'd like to do things in a Rackety way. But I'm not above > doing things the silly way. I'd just be grumpy about it. > >> > > >> > Any ideas? > >> > > >> > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to racket-users+unsubscr...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com > . > > > > > > > > -- > > > > > > Stephen Foster > > ThoughtSTEM Co-Founder > > 318-792-2035 > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CA%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%40mail.gmail.com > . > -- Stephen Foster ThoughtSTEM Co-Founder 318-792-2035 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CA%2BzSu2_1TNmiycyM9L_uTrpAoAQR%3DUX%2BJsm80uOFDNLO%3Du7Y1g%40mail.gmail.com.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
Curl supports http/2 (and even has experimental support for http/3 which is orders of magnitude faster than http/1.1. Depending on what protocols the server you're talking to supports, that could be part of it. On Monday, September 14, 2020 at 3:42:37 PM UTC-7 samdph...@gmail.com wrote: > Hi Stephen, > > I ran this small benchmark against a remote web server, and was > definitely getting better response using the http-easy module. > > https://gist.github.com/samdphillips/32763ebd0d938678c2972b1dd8ee5778 > > $ racket -e '(require (submod "http-perf.rkt" curl))' > cpu time: 768 real time: 35299 gc time: 0 > > $ racket -e '(require (submod "http-perf.rkt" http-easy))' > cpu time: 1810 real time: 17316 gc time: 70 > > On Mon, Sep 14, 2020 at 12:57 PM Stephen Foster > wrote: > > > > Finally circling back to this issue. I've disabled debugging in DrRacket > and also done a test outside of DrRacket. It's still slow. :( > > > > I also tried the newer HTTP client: > https://docs.racket-lang.org/http-easy/index.html. Like the others, it is > also slow. > > > > I'll do some more digging. I'm currently trying to figure out if this is > a "just me" / "just my system" problem. So... I'd be grateful if anyone who > has written code that sends HTTP requests from Racket could chime in with: > 1) I can confirm that sending HTTP requests from Racket has always been > fast for me, or 2) I too have noticed Racket HTTP requests are slow. > > > > (Note that by "slow", I mean: takes noticeably longer than curl.) > > > > > > > > On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri wrote: > >> > >> Hi Stephen, > >> > >> Your video shows you running this code in DrRacket with debugging > >> enabled. That usually affects performance. Have you made measurements > >> when running this code outside of DrRacket? > >> > >> - Jon > >> > >> > >> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster > wrote: > >> > > >> > I'm considering using Racket to remake my 3D game CodeSpells. I'm > using http requests to have Unreal Engine and Racket talk to each other. > >> > > >> > When I use the http/request library, Racket fires off its GET request > much slower than if it were to do a system call to curl. (Same is true if I > use simple-http, which makes me think the problem might be a deep one.) > >> > > >> > Here's a video to demo the issue. Notice how, with curl, the > experience is playable, whereas with the Racket function, there's way too > much time between the spell landing and the effect occurring: > >> > > >> > https://youtu.be/jTqUFVlfBFA > >> > > >> > Obviously, I'd like to do things in a Rackety way. But I'm not above > doing things the silly way. I'd just be grumpy about it. > >> > > >> > Any ideas? > >> > > >> > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to racket-users...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com > . > > > > > > > > -- > > > > > > Stephen Foster > > ThoughtSTEM Co-Founder > > 318-792-2035 <(318)%20792-2035> > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CA%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/1c8664fa-e8f2-49c8-8417-101dd7186231n%40googlegroups.com.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
Hi Stephen, I ran this small benchmark against a remote web server, and was definitely getting better response using the http-easy module. https://gist.github.com/samdphillips/32763ebd0d938678c2972b1dd8ee5778 $ racket -e '(require (submod "http-perf.rkt" curl))' cpu time: 768 real time: 35299 gc time: 0 $ racket -e '(require (submod "http-perf.rkt" http-easy))' cpu time: 1810 real time: 17316 gc time: 70 On Mon, Sep 14, 2020 at 12:57 PM Stephen Foster wrote: > > Finally circling back to this issue. I've disabled debugging in DrRacket and > also done a test outside of DrRacket. It's still slow. :( > > I also tried the newer HTTP client: > https://docs.racket-lang.org/http-easy/index.html. Like the others, it is > also slow. > > I'll do some more digging. I'm currently trying to figure out if this is a > "just me" / "just my system" problem. So... I'd be grateful if anyone who > has written code that sends HTTP requests from Racket could chime in with: 1) > I can confirm that sending HTTP requests from Racket has always been fast for > me, or 2) I too have noticed Racket HTTP requests are slow. > > (Note that by "slow", I mean: takes noticeably longer than curl.) > > > > On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri wrote: >> >> Hi Stephen, >> >> Your video shows you running this code in DrRacket with debugging >> enabled. That usually affects performance. Have you made measurements >> when running this code outside of DrRacket? >> >> - Jon >> >> >> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster >> wrote: >> > >> > I'm considering using Racket to remake my 3D game CodeSpells. I'm using >> > http requests to have Unreal Engine and Racket talk to each other. >> > >> > When I use the http/request library, Racket fires off its GET request much >> > slower than if it were to do a system call to curl. (Same is true if I >> > use simple-http, which makes me think the problem might be a deep one.) >> > >> > Here's a video to demo the issue. Notice how, with curl, the experience >> > is playable, whereas with the Racket function, there's way too much time >> > between the spell landing and the effect occurring: >> > >> > https://youtu.be/jTqUFVlfBFA >> > >> > Obviously, I'd like to do things in a Rackety way. But I'm not above >> > doing things the silly way. I'd just be grumpy about it. >> > >> > Any ideas? >> > >> > >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Racket Users" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to racket-users+unsubscr...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com. > > > > -- > > > Stephen Foster > ThoughtSTEM Co-Founder > 318-792-2035 > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CA%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAHsjV0ytpkiHvb%2BtXXW6iEcB1HMxVsUkkmWY-NGmEDBJ_fUR9Q%40mail.gmail.com.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
I ran a few tests where I fetch the google homepage via curl, get-impure-port, and get-impure-port*. Curl does, in fact, seem to be faster, but not nearly so much so to account for the delays in that video. So, one thing to check is if the racket code gets slower results when requesting arbitrary urls vs. when requesting that specific server. It could be an issue with the requests headers that you're sending (which is to say, the library defaults) vs. what curl is sending. Or it could be a bad interaction with Nagle's algorithm, though that seems unlikely with an http GET, since the most likely culprit would be separate flushes of header and body data -- and there is no body in a GET request. I think maybe all of the things you tried use http 1.0 requests by default (simple-http reuses the code from net/http-client), so you might want to try explicitly using 1.1. On Mon, Sep 14, 2020 at 3:57 PM Stephen Foster wrote: > > Finally circling back to this issue. I've disabled debugging in DrRacket and > also done a test outside of DrRacket. It's still slow. :( > > I also tried the newer HTTP client: > https://docs.racket-lang.org/http-easy/index.html. Like the others, it is > also slow. > > I'll do some more digging. I'm currently trying to figure out if this is a > "just me" / "just my system" problem. So... I'd be grateful if anyone who > has written code that sends HTTP requests from Racket could chime in with: 1) > I can confirm that sending HTTP requests from Racket has always been fast for > me, or 2) I too have noticed Racket HTTP requests are slow. > > (Note that by "slow", I mean: takes noticeably longer than curl.) > > > > On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri wrote: >> >> Hi Stephen, >> >> Your video shows you running this code in DrRacket with debugging >> enabled. That usually affects performance. Have you made measurements >> when running this code outside of DrRacket? >> >> - Jon >> >> >> On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster >> wrote: >> > >> > I'm considering using Racket to remake my 3D game CodeSpells. I'm using >> > http requests to have Unreal Engine and Racket talk to each other. >> > >> > When I use the http/request library, Racket fires off its GET request much >> > slower than if it were to do a system call to curl. (Same is true if I >> > use simple-http, which makes me think the problem might be a deep one.) >> > >> > Here's a video to demo the issue. Notice how, with curl, the experience >> > is playable, whereas with the Racket function, there's way too much time >> > between the spell landing and the effect occurring: >> > >> > https://youtu.be/jTqUFVlfBFA >> > >> > Obviously, I'd like to do things in a Rackety way. But I'm not above >> > doing things the silly way. I'd just be grumpy about it. >> > >> > Any ideas? >> > >> > >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Racket Users" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to racket-users+unsubscr...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com. > > > > -- > > > Stephen Foster > ThoughtSTEM Co-Founder > 318-792-2035 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAKfDxxyzT9z9inrjoLumvK%3DZi4CNpBo0RpMuOkkwUs4WG2g4Gg%40mail.gmail.com.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
Finally circling back to this issue. I've disabled debugging in DrRacket and also done a test outside of DrRacket. It's still slow. :( I also tried the newer HTTP client: https://docs.racket-lang.org/http-easy/index.html. Like the others, it is also slow. I'll do some more digging. I'm currently trying to figure out if this is a "just me" / "just my system" problem. So... I'd be grateful if anyone who has written code that sends HTTP requests from Racket could chime in with: 1) I can confirm that sending HTTP requests from Racket has always been fast for me, or 2) I too have noticed Racket HTTP requests are slow. (Note that by "slow", I mean: takes noticeably longer than curl.) On Tue, Jul 7, 2020 at 12:21 PM Jon Zeppieri wrote: > Hi Stephen, > > Your video shows you running this code in DrRacket with debugging > enabled. That usually affects performance. Have you made measurements > when running this code outside of DrRacket? > > - Jon > > > On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster > wrote: > > > > I'm considering using Racket to remake my 3D game CodeSpells. I'm using > http requests to have Unreal Engine and Racket talk to each other. > > > > When I use the http/request library, Racket fires off its GET request > much slower than if it were to do a system call to curl. (Same is true if > I use simple-http, which makes me think the problem might be a deep one.) > > > > Here's a video to demo the issue. Notice how, with curl, the experience > is playable, whereas with the Racket function, there's way too much time > between the spell landing and the effect occurring: > > > > https://youtu.be/jTqUFVlfBFA > > > > Obviously, I'd like to do things in a Rackety way. But I'm not above > doing things the silly way. I'd just be grumpy about it. > > > > Any ideas? > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com > . > -- Stephen Foster ThoughtSTEM Co-Founder 318-792-2035 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CA%2BzSu2_%2BTKVTe--OZRU_BE_LyofFkA869c-2v%2BRJ76HjDQt4_w%40mail.gmail.com.
Re: [racket-users] Why is get-impure-port* slower than a system call to curl?
Hi Stephen, Your video shows you running this code in DrRacket with debugging enabled. That usually affects performance. Have you made measurements when running this code outside of DrRacket? - Jon On Tue, Jul 7, 2020 at 2:13 PM Stephen Foster wrote: > > I'm considering using Racket to remake my 3D game CodeSpells. I'm using http > requests to have Unreal Engine and Racket talk to each other. > > When I use the http/request library, Racket fires off its GET request much > slower than if it were to do a system call to curl. (Same is true if I use > simple-http, which makes me think the problem might be a deep one.) > > Here's a video to demo the issue. Notice how, with curl, the experience is > playable, whereas with the Racket function, there's way too much time between > the spell landing and the effect occurring: > > https://youtu.be/jTqUFVlfBFA > > Obviously, I'd like to do things in a Rackety way. But I'm not above doing > things the silly way. I'd just be grumpy about it. > > Any ideas? > > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAKfDxxx2%2BrwSw1FiDXvtw9ErNXor-QffeUF21%2BNpsiM%2BZviRNQ%40mail.gmail.com.
[racket-users] Why is get-impure-port* slower than a system call to curl?
I'm considering using Racket to remake my 3D game CodeSpells. I'm using http requests to have Unreal Engine and Racket talk to each other. When I use the http/request library, Racket fires off its GET request much slower than if it were to do a system call to curl. (Same is true if I use simple-http, which makes me think the problem might be a deep one.) Here's a video to demo the issue. Notice how, with curl, the experience is playable, whereas with the Racket function, there's way too much time between the spell landing and the effect occurring: https://youtu.be/jTqUFVlfBFA Obviously, I'd like to do things in a Rackety way. But I'm not above doing things the silly way. I'd just be grumpy about it. Any ideas? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/997693d6-b94a-4f69-85cf-aa475c807b20n%40googlegroups.com.
