Thanks for the responses.
I took a look at the generated code and go-bindata does in fact use the
form "var _data = []byte(`my giant string`)".
But there's something strange happening: I can't reproduce the problem
on my Macbook Pro. It compiles just fine here.
On Mon, Jan 9, 2017, at 12:50 AM, Pierre Durand wrote:
> This option ?
> https://github.com/jteeuwen/go-bindata#lower-memory-footprint
>
> Le dimanche 8 janvier 2017 21:46:15 UTC+1, Dave Cheney a écrit :
>> This is a somewhat known issue. Each token in a parsered .go file is
>> represented by a Node structure inside the program. The Node
>> structure is large, especially on 64 bit systems.
>> Normally this is not a problem, but in th e case where code has large
>> tables of data memory usage when compiling can be unexpectedly high.
>> This problem is being worked on, but not solution exists in a
>> shipping version of Go yet.
>> The mitigation to this problem is to reduce the number of parsed
>> tokens, so, rather than
>> var data = []byte{ 65, 66, 67, 68, 69, 70}
>> Do
>> const data = "abcdef"
>> The latter produces O(1) tokens per declaration vs O(N) tokens for
>> the former.
>> If the data cannot be represented as text, compressing and base64
>> encoding can help.
>> I'm not sure what strategy go-bindata uses, but you can check this
>> yourself looking at its generated output.
>> Dave
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> 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.
--
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.
