Michael,
n your code, you have :
const n = 1000 * 1000
for i := 0; i < n && scan.Scan(); i++ {
d, _ := strconv.Atoi(scan.Text())
array[i] = int64(d)
}
https://play.golang.org/p/SgpAXyvsGs
Here's a benchmark that demonstrates the fundamental issue, unnecessary
string conversions.
,
BenchmarkAtoiBytconv-4 50000000 30.4 ns/op 0 B/op 0
allocs/op
BenchmarkAtoiStrconv-4 20000000 102 ns/op 8 B/op 1
allocs/op
https://play.golang.org/p/oSQ8RZeGL7
Peter
On Thursday, August 31, 2017 at 12:24:20 PM UTC-4, peterGo wrote:
>
> Michael,
>
> Your read times look slow to me. I used bytconv instead of strconv.
>
> bytconv:
> read 1000000 98.517584ms
> sort 1000000 481.994354ms
>
> strconv:
> read 1000000 174.720883ms
> sort 1000000 479.437831ms
>
> bytconv is the missing Go standard library package. bytconv is the byte
> input analog of string input strconv.
>
> Peter
>
> On Wednesday, August 30, 2017 at 7:43:49 PM UTC-4, Michael Jones wrote:
>>
>> good point. I was trying to show that the buffered stdin was "just like"
>> normal scanning but the performance was less compared to the updated
>> scanning code.
>>
>> here is another version, this time with a data generator and since the
>> input is line oriented, the default split function is fine.
>>
>> https://play.golang.org/p/SgpAXyvsGs
>> read 1000000 65.362993ms
>> sort 1000000 187.092493ms
>>
>>
>> On Wed, Aug 30, 2017 at 2:56 PM, Patrick Smith <pat42...@gmail.com>
>> wrote:
>>
>>> That is simpler, but slower. Not nearly as slow as using unbuffered io
>>> though. Timings on my machine, reading 1e6 integers chosen randomly from
>>> the range [0,1e18):
>>>
>>> Original code https://play.golang.org/p/grB-muK7hw
>>> 5.626974435s
>>> 155.367779ms
>>>
>>> Original poster's optimized code https://play.golang.org/p/1Aoxwwv-zo
>>> 168.638597ms
>>> 150.923225ms
>>>
>>> Michael's simpler code https://play.golang.org/p/tMyipz6sYU
>>> 954.543351ms
>>> 166.710399ms
>>>
>>> So this is about 6 times slower. My guess is this is due to the use of
>>> reflection in fmt.Fscanf. But that is just a guess; I don't really have any
>>> evidence to back it up.
>>>
>>> On Wed, Aug 30, 2017 at 1:33 PM, Michael Jones <michae...@gmail.com>
>>> wrote:
>>>
>>>> This can be much simpler...
>>>> https://play.golang.org/p/tMyipz6sYU
>>>>
>>>> On Wed, Aug 30, 2017 at 7:55 AM, Nilsocket <nils...@gmail.com> wrote:
>>>>
>>>>>
>>>>> Can you provide example code for how you read the input?
>>>>>>
>>>>>
>>>>> Both of them were given same input size is:1000000, (i.e., 1 million)
>>>>>
>>>>> https://play.golang.org/p/grB-muK7hw
>>>>> // Time taken to read input : 9.840256889s
>>>>> // Time taken to sort: 731.469604ms
>>>>>
>>>>> I have implemented the same using bufio:
>>>>>
>>>>> https://play.golang.org/p/1Aoxwwv-zo
>>>>> // Time taken to read input : 377.038152ms
>>>>> // Time taken to sort: 688.20638ms
>>>>>
>>>>> --
>>>>> 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...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael T. Jones
>>>> michae...@gmail.com
>>>>
>>>> --
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>
>>
>> --
>> Michael T. Jones
>> michae...@gmail.com
>>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
