<FromGitter>
<wout> In many specs I am initializing the same object. In RSpec we have `subject { object = Object.new }`. Is there something similar in Crystal's Spec?
<FromGitter>
<wout> Or should I just use a method? Like:
<FromGitter>
<j8r> I think that the use of a Hash is not as efficient as a Radix tree
gangstacat has quit [Quit: ฤis!]
<FromGitter>
<j8r> I wonder how can I change that... I could use an array
<FromGitter>
<Blacksmoke16> are routes immutable?
<FromGitter>
<Blacksmoke16> could build the route tree out using a named tuple
<FromGitter>
<Blacksmoke16> also could try only instantiating the hash once versus on each request (if thats something you're not already doing)
gangstacat has joined #crystal-lang
<FromGitter>
<j8r> routes are added at runtime :/
<FromGitter>
<j8r> and yes no hash is created (only one to store params)
<FromGitter>
<Blacksmoke16> hmm, could profile it to see whats being slow
<FromGitter>
<Blacksmoke16> also could prob run it with the debug PR branch and use https://github.com/RX14/coz.cr to identity things that would bring the biggest boost
<FromGitter>
<j8r> Maybe, but here I don't see anything that can slow down except hashing the slice/string
<FromGitter>
<stronny> does this even matter? how often are routes being read?
<FromGitter>
<j8r> if `/a/b/c` is sent, `a`, `b` and `c` will be hashed
<FromGitter>
<stronny> why is this a problem?
<FromGitter>
<j8r> hashing is notoriously not very fast
<FromGitter>
<j8r> matching chars like Radix would be faster
<FromGitter>
<stronny> are you doing a premature optimization?
<FromGitter>
<j8r> not really, the base of the framework is now done
<FromGitter>
<stronny> I think you should profile an organic application
<FromGitter>
<stronny> comparing hello worlds is a sport, not something useful
<FromGitter>
<Blacksmoke16> i didnt look too much into it but i assume the thing that slows down athena is the service container
<FromGitter>
<Blacksmoke16> newing up n objects on every request
gangstacat has quit [Quit: ฤis!]
gangstacat has joined #crystal-lang
<FromGitter>
<kinxer> Does the Crystal standard library have anything for making byte counts more human readable (like `ls -lh`)?
<FromGitter>
<Blacksmoke16> is a balance between speed and convenience/features
<FromGitter>
<j8r> Yep, and at the end if the real application needs to cast โ there won't be much change
<FromGitter>
<j8r> minus less safety
<FromGitter>
<Blacksmoke16> mhm
<FromGitter>
<Blacksmoke16> rails on the list is like 2500/sec
<FromGitter>
<Blacksmoke16> im at like 130k/sec, not going to put in so much effort trying to make something that is already well fast enough
<FromGitter>
<j8r> Right
<FromGitter>
<Blacksmoke16> try and be top of the list
<FromGitter>
<Blacksmoke16> rather be focusing on QoL and core framework improvements
<FromGitter>
<j8r> Maybe, that's also a way to promote a project
<FromGitter>
<j8r> Like Crystal
<FromGitter>
<j8r> I will spend a bit of time, learn new things
<FromGitter>
<Blacksmoke16> IMO it comes down to the ecosystem of the framework versus how fast it is most of the time
<FromGitter>
<j8r> You're right, not too much :)
<FromGitter>
<Blacksmoke16> one thing i thought of, might not be a bad idea to provide test utilities
<FromGitter>
<Blacksmoke16> i.e. `require "athena/spec"`, which would provide methods and mocks to make testing stuff easier. In future this could include like integration test logic etc
<FromGitter>
<Blacksmoke16> one thing i thought of, might not be a bad idea to provide test utilities
<FromGitter>
<j8r> Good idea!
<FromGitter>
<Blacksmoke16> i dont really recall seeing much about how to test an amber/lucky controller for example
<FromGitter>
<Blacksmoke16> outside of E2E tests at least
<FromGitter>
<dburnsii> Is there an easy way to send a GET request to a unix socket? Currently using the `HTTP::Server.bind_unix` to create the server and that seems to work, but `HTTP::Client` doesn't accept the `unix://` path
<FromGitter>
<j8r> I will refactor my node tree as a Radix tree, good time to learn more about it
<FromGitter>
<dscottboggs_gitlab> well, a struct that contains a `Pointer(UInt8)` and UInt32 noting the size of the struct
<FromGitter>
<stronny> trees are O(log N) on access, while hashes are O(N + k)
<FromGitter>
<stronny> you may see even less speed
<FromGitter>
<j8r> but the operation to hash is huge, compared to match integers
<FromGitter>
<dscottboggs_gitlab> only one way to find out
<FromGitter>
<j8r> And note the hashing is done for each path segment
<FromGitter>
<stronny> depends on a hash function
<FromGitter>
<stronny> also does not depend on element count, unlike a tree
<FromGitter>
<stronny> what's the usecase?
<FromGitter>
<dscottboggs_gitlab> if it's O(log n) then wouldn't it be less expensive for larger datasets and matter less for smaller datasets? that sounds ideal to me
<FromGitter>
<stronny> of course there is no one universally best data structure
<FromGitter>
<stronny> for larger datasets that would be less expensive than brute force search like O(N), but much more expensive than O(1)
<FromGitter>
<dscottboggs_gitlab> In the words of Bjarne Stroustrup, โ โ > If your reason is โefficiency,โ measure. Our intuition is most fallible in matters of the performance of container uses.
<FromGitter>
<stronny> well, Bjarne is no authority to me, but that's exactly what I've said to Julien: you are wasting your time on a premature optimisation that would matter nothing in a real application
<FromGitter>
<dscottboggs_gitlab> Idk even though it was a footnote, that line really struck me when I read *A Tour of C++*. I don't make un-hedged claims about performance since then
<FromGitter>
<dscottboggs_gitlab> I'm saying something different though. I'm saying he should try it and test which implementation is faster under which circumstances
<FromGitter>
<stronny> why?
<FromGitter>
<stronny> I say do what's easier, performance means nothing here
<FromGitter>
<dscottboggs_gitlab> It depends on the use-case?
<FromGitter>
<stronny> he needs a Routes storage
<FromGitter>
<dscottboggs_gitlab> that's what I thought it was. How is performance not critical?
<FromGitter>
<stronny> in a typical http request a route lookup is negligible
<FromGitter>
<stronny> it's unnoticable even comparing to HTTP parsing
<FromGitter>
<stronny> saying nothing about an actual payload
<FromGitter>
<wout> I'm getting a strange error installing a shard: `Failed git ls-tree -r --full-tree --name-only v1.0.0 -- shard.yml (). Maybe a commit, branch or file doesn't exist?`. Adding `branhc: master` to the dependency in shards.yml fixes the issue. But why am I seeing this?
<FromGitter>
<wout> @stronny Should tags for shards always be prefixed with `v`?
<FromGitter>
<stronny> I've somewhere that it's indeed the current convention
<FromGitter>
<wout> Good to know. :)
<FromGitter>
<dscottboggs_gitlab> > Should tags for shards always be prefixed with v?
<FromGitter>
<dscottboggs_gitlab> yes
<FromGitter>
<dscottboggs_gitlab> > in a typical http request a route lookup is negligible โ โ that's a fair point, but I'm not sure that I agree that an efficiently written HTTP parser that reuses the source buffer would necessarily take less time
alexherbo2 has quit [Ping timeout: 268 seconds]
_ht has quit [Remote host closed the connection]
<FromGitter>
<j8r> I have to say the router is not the bottleneck
<FromGitter>
<j8r> I hard-coded the resolution
<FromGitter>
<j8r> for testing purposes
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 265 seconds]
<FromGitter>
<Blacksmoke16> did that help?
<FromGitter>
<j8r> I end up commenting everything, and the performance is still near the same...
<FromGitter>
<Blacksmoke16> ๐ฎ
<FromGitter>
<Blacksmoke16> hm
<FromGitter>
<j8r> it improved by 10%, only
<FromGitter>
<j8r> not sure what's the reason
<FromGitter>
<Blacksmoke16> :shrug:
<FromGitter>
<j8r> ho, I forgot reuse_port - may be that?