FAQ
Hi! I'm use http.FileServer and dont want additional read/seek
requests to determine mine type for content-type header. Does it
possible to disable this?
Or i need to create own FileServer implementation ?

--
Vasiliy Tolstov,
e-mail: v.tolstov@selfip.ru

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Giulio Iotti at Nov 13, 2015 at 10:14 am

    On Friday, November 13, 2015 at 10:43:13 AM UTC+1, Vasiliy Tolstov wrote:
    Hi! I'm use http.FileServer and dont want additional read/seek
    requests to determine mine type for content-type header. Does it
    possible to disable this?
    Disable as in always put the header Content-Type:
    application/octect-stream? I guess you can implement/extend yours.

    Question is: are you sure the seek is causing you a performance impact?

    Once you fire a read, contents are cached by the filesystems. A seek and
    another read cost almost nothing.

    --
    Giulio Iotti


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Vasiliy Tolstov at Nov 13, 2015 at 10:22 am

    2015-11-13 13:14 GMT+03:00 Giulio Iotti <dullgiulio@gmail.com>:
    Question is: are you sure the seek is causing you a performance impact?

    Once you fire a read, contents are cached by the filesystems. A seek and
    another read cost almost nothing.

    If this is real file system - thats true. But i have virtual fs in
    this case contents stored in memory and i don't think that if i know
    that all data text/plain i need to read it twice (even this data
    already in memory)


    --
    Vasiliy Tolstov,
    e-mail: v.tolstov@selfip.ru

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Giulio Iotti at Nov 13, 2015 at 10:29 am

    On Friday, November 13, 2015 at 11:22:23 AM UTC+1, Vasiliy Tolstov wrote:
    If this is real file system - thats true. But i have virtual fs in
    this case contents stored in memory and i don't think that if i know
    that all data text/plain i need to read it twice (even this data
    already in memory)
    Then it's really a micro-optimization.

    Anyway, if you set the header Content-Type before ServeFile, no seek is
    performed[1].

    You need to implement a handler that sets the header then calls the
    ServeFile handler.


    [1] https://golang.org/src/net/http/fs.go#L142
    --
    Giulio Iotti

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Vasiliy Tolstov at Nov 13, 2015 at 12:03 pm

    2015-11-13 13:29 GMT+03:00 Giulio Iotti <dullgiulio@gmail.com>:
    Then it's really a micro-optimization.
    Yes, but in why not do it if this is simple =)
    Anyway, if you set the header Content-Type before ServeFile, no seek is
    performed[1].

    You need to implement a handler that sets the header then calls the
    ServeFile handler.
    Yes, as i see i simply need to create own FileServer that runs
    ServeContent with specified content-type



    --
    Vasiliy Tolstov,
    e-mail: v.tolstov@selfip.ru

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Wheelcomplex at Nov 14, 2015 at 1:30 pm
    thanks for the tips :P
    On Friday, November 13, 2015 at 8:04:03 PM UTC+8, Vasiliy Tolstov wrote:

    2015-11-13 13:29 GMT+03:00 Giulio Iotti <dullg...@gmail.com <javascript:>>:
    Then it's really a micro-optimization.
    Yes, but in why not do it if this is simple =)
    Anyway, if you set the header Content-Type before ServeFile, no seek is
    performed[1].

    You need to implement a handler that sets the header then calls the
    ServeFile handler.
    Yes, as i see i simply need to create own FileServer that runs
    ServeContent with specified content-type



    --
    Vasiliy Tolstov,
    e-mail: v.to...@selfip.ru <javascript:>
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Charles Haynes at Nov 17, 2015 at 3:55 am

    On Fri, 13 Nov 2015 at 23:03 Vasiliy Tolstov wrote:

    2015-11-13 13:29 GMT+03:00 Giulio Iotti <dullgiulio@gmail.com>:
    Then it's really a micro-optimization.
    Yes, but in why not do it if this is simple =)
    I know you put a smiley, but it's a good question and deserves a serious
    answer:
    From https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

    Optimization can reduce readability
    <https://en.wikipedia.org/wiki/Readability> and add code that is used only
    to improve the performance
    <https://en.wikipedia.org/wiki/Computer_performance>. This may complicate
    programs or systems, making them harder to maintain and debug. As a result,
    optimization or performance tuning is often performed at the end of
    thedevelopment
    stage <https://en.wikipedia.org/wiki/Development_stage>.

    Donald Knuth <https://en.wikipedia.org/wiki/Donald_Knuth> made the
    following two statements on optimization:
    "We should forget about small efficiencies, say about 97% of the time:
    premature optimization is the root of all evil. Yet we should not pass up
    our opportunities in that critical 3%"[3]
    <https://en.wikipedia.org/wiki/Program_optimization#cite_note-autogenerated268-3>


    The reason not to do it is because it makes the code harder to read and
    understand for what you agree is almost no benefit. The cost will come to
    the person (maybe you!) trying to understand this code a year from now. The
    cost will be to the person cutting and pasting this code into a new context
    in which the optimization doesn't apply because the file type is not known
    in advance.

    For program optimizations, you should have a concrete measurable reason
    "why" and not just "why not?" The simple rule is: if you're asking if you
    should optimize the answer is "no." When it's time to optimise you will
    *know* - you'll know why, and you'll know where - because you've measured.

    -- Charles

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 13, '15 at 9:43a
activeNov 17, '15 at 3:55a
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase