FAQ
Dears,

I've been rewritten my Java project to Go and I met a question lately. In
Java, RandomAccessFile is used to do random read, and it's safe to keep
RandomAccessFile instance in memory, with proper close() when it's done.
For Go version, is it a good practise to keep os.File in memory, or should
I allocate one for every read (with buffer enabled of course)?

It's a performance question and I can benchmark myself later...but I'm
wondering if anyone has some quick suggestion first.

Thanks,

-- Ian

--
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/groups/opt_out.

Search Discussions

  • Ian Lance Taylor at Jun 14, 2013 at 1:23 pm

    On Fri, Jun 14, 2013 at 5:28 AM, 周益琰 wrote:
    I've been rewritten my Java project to Go and I met a question lately. In
    Java, RandomAccessFile is used to do random read, and it's safe to keep
    RandomAccessFile instance in memory, with proper close() when it's done. For
    Go version, is it a good practise to keep os.File in memory, or should I
    allocate one for every read (with buffer enabled of course)?

    It's a performance question and I can benchmark myself later...but I'm
    wondering if anyone has some quick suggestion first.
    Normally you would use a single os.File to read from a file, and use
    the ReadAt method to read data from random locations.

    Ian

    --
    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/groups/opt_out.
  • 周益琰 at Jun 16, 2013 at 7:20 am
    It makes sense to me.

    One more question, should I prefer ReadAt to Seek/Read if I don't keep real
    location? Or, does underlying infrastructure pre-buffer or benefit from
    persisted position by using seek method?

    在 2013年6月14日星期五UTC+8下午9时23分51秒,Ian Lance Taylor写道:
    On Fri, Jun 14, 2013 at 5:28 AM, 周益琰 <balz...@gmail.com <javascript:>>
    wrote:
    I've been rewritten my Java project to Go and I met a question lately. In
    Java, RandomAccessFile is used to do random read, and it's safe to keep
    RandomAccessFile instance in memory, with proper close() when it's done. For
    Go version, is it a good practise to keep os.File in memory, or should I
    allocate one for every read (with buffer enabled of course)?

    It's a performance question and I can benchmark myself later...but I'm
    wondering if anyone has some quick suggestion first.
    Normally you would use a single os.File to read from a file, and use
    the ReadAt method to read data from random locations.

    Ian
    --
    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/groups/opt_out.
  • Ian Lance Taylor at Jun 16, 2013 at 10:47 pm

    On Sun, Jun 16, 2013 at 12:20 AM, 周益琰 wrote:
    One more question, should I prefer ReadAt to Seek/Read if I don't keep real
    location? Or, does underlying infrastructure pre-buffer or benefit from
    persisted position by using seek method?
    In general a single ReadAt call is going to be better than separate
    Seek and Read calls. It doesn't make a big difference, but if you
    have an easy choice in your program you should prefer ReadAt.

    Ian

    --
    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/groups/opt_out.
  • Voidlogic7 at Jun 17, 2013 at 3:15 am
    Also if you have multiple goroutines reading the same os.File you definatly
    need to use ReadAt. If you do this you probably want to use a RW mutex to
    guard the os.File.
    On Sunday, June 16, 2013 5:47:24 PM UTC-5, Ian Lance Taylor wrote:

    On Sun, Jun 16, 2013 at 12:20 AM, 周益琰 <balz...@gmail.com <javascript:>>
    wrote:
    One more question, should I prefer ReadAt to Seek/Read if I don't keep real
    location? Or, does underlying infrastructure pre-buffer or benefit from
    persisted position by using seek method?
    In general a single ReadAt call is going to be better than separate
    Seek and Read calls. It doesn't make a big difference, but if you
    have an easy choice in your program you should prefer ReadAt.

    Ian
    --
    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/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 14, '13 at 12:28p
activeJun 17, '13 at 3:15a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase