ObjFW  History Of Ticket c34a429b8c

Artifacts Associated With Ticket c34a429b8c

1. Ticket change [e8e1d99b1a] (rid 40114) by js on 2022-10-20 16:41:25:

   1. icomment:

      Currently this goes through the `OFURIHandler` for `file:`. This means the generic code is used that grows a buffer, while `-[initWithContentsOfFile:]` is more optimized and only needs to allocate the buffer once. It would make sense to either add a specialization to fall back to `-[initWithContentsOfFile:]` on `file:` or to generalize it and always check if the returned stream is a `OFSeekableStream`, allowing to just seek to the end of the stream to get its size. However, for networked protocols, that *might* have negative performance implications, so it might be safer to just add a specialization for `file:`.
      

   2. login: "js"
   3. milestone initialized to: "none"
   4. mimetype: "text/x-markdown"
   5. priority initialized to: "Medium"
   6. severity initialized to: "Minor"
   7. status initialized to: "Open"
   8. title initialized to: "Optimize initWithContentsOfURI: with file: URIs"
   9. type initialized to: "Enhancement"

2. Ticket change [e521a9bb7f] (rid 44440) by js on 2024-01-20 21:46:22:

   1. login: "js"
   2. milestone changed to: "1.1"
   3. mimetype: "text/x-markdown"
   4. resolution changed to: "Open"
   5. title changed to: "Optimize initWithContentsOfIRI: with file: IRIs"

3. Ticket change [b14aa02def] (rid 45719) by js on 2024-03-09 20:33:43:

   1. icomment:

      This is obsolete as `-[initWithContentsOfFile:]` is just calling into `-[initWithContentsOfIRI:]` anyway. Yes, it's possible to check the size first and allocate the buffer, but that has problems if the size changes. Hence, this is probably an optimization not worth it. Memory mapped data and strings probably make more sense.
      

   2. login: "js"
   3. milestone changed to: "none"
   4. mimetype: "text/x-markdown"
   5. resolution changed to: "Overcome_By_Events"
   6. status changed to: "Closed"