Render directly to IO

[paulcsmith]

https://stackoverflow.com/questions/50774451/how-to-free-memory-allocated-for-some-structure-in-crystal-manually/50782379#50782379

For both JSON and HTML pages.

Right now I don't think this is a big deal as performance is already excellent, but this should be done eventually

[jwoertink]

I've been thinking about this, and trying to wrap my head around how this actually would work. I think the final output sent to the user is here. I think body at this point is either the HTML, or the JSON that's to be rendered to the user. If I understand this correctly, then context.response is an IO::Memory, and body what too at some point before this. So when we render directly to the IO, is it this context.response we would be writing to? If so, could we just set the view here to be context.response?

[paulcsmith]

Yeah I think that could be done, but then it changes how `html` and `TextResponse` work since right now you call `print` on TextResponse and then it writes to the view. So maybe we could have an `HTMLResponse` that just sets the status and headers since the HTML was already written? The same could be done for JSON as well.

…

On Mar 9, 2020, 11:21 AM -0400, Jeremy Woertink ***@***.***>, wrote: I've been thinking about this, and trying to wrap my head around how this actually would work. I think the final output sent to the user is here. I think body at this point is either the HTML, or the JSON that's to be rendered to the user. If I understand this correctly, then context.response is an IO::Memory, and body what too at some point before this. So when we render directly to the IO, is it this context.response we would be writing to? If so, could we just set the view here to be context.response? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[paulcsmith]

Actually this might be bad...or need to be rethought. I'm not sure if as soon as you write to the response it starts streaming to the client. if so this would be a problem because it may encounter an error and have a half written HTML response and then raise a 500. I'm hoping that it doesn't just start streaming...but maybe it does.

[jwoertink]

Yeah, probably would need lots of tests around that. I'm just not too familiar with the concept, so I was trying to think of what are these steps. Maybe I'll mess around with it a bit and test that later if I get some time.

[paulcsmith]

Sounds good! I don’t think it will be much of a perf improvement based on some tests I did with copying strings v. writing directly. But if we can do it and not introduce more complexity it’d be great

…

On Mar 9, 2020, 11:58 AM -0400, Jeremy Woertink ***@***.***>, wrote: Yeah, probably would need lots of tests around that. I'm just not too familiar with the concept, so I was trying to think of what are these steps. Maybe I'll mess around with it a bit and test that later if I get some time. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.