ObjFW  View Ticket

2024-05-22
20:18 Ticket [c34a429b8c] Optimize initWithContentsOfIRI: with file: IRIs status still Closed with 3 other changes artifact: cd514ef008 user: js
00:11 Ticket [c34a429b8c]: 3 changes artifact: 99914f5124 user: js
2024-03-09
20:33 Closed ticket [c34a429b8c]. artifact: b14aa02def user: js
2024-01-20
21:46 Ticket [c34a429b8c]: 5 changes artifact: e521a9bb7f user: js
2022-10-20
16:41 New ticket [c34a429b8c]. artifact: e8e1d99b1a user: js

Ticket UUID: c34a429b8cd54bc99eaad51fa400932cf48db300
Title: Optimize initWithContentsOfIRI: with file: IRIs
Status: Closed Type: Enhancement
Severity: Minor Priority: Medium
Subsystem: Resolution: Overcome By Events
Last Modified: 2024-05-22 20:18:12
Version Found In: Milestone:
User Comments:
js added on 2022-10-20 16:41:25:

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:.


js added on 2024-03-09 20:33:43:

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.