I've not seen much talk about the public preview of Profile Guided
Optimisation available in v1.20.
I'd not even heard that this feature was being planned until an
acquaintance mentioned it this evening. I read the blog and tried it out.
Very simple feature to use. I'm getting 10% performance
On Thursday, September 15, 2022 at 4:01:59 AM UTC+1 ren...@ix.netcom.com
wrote:
> Is there any way to perform “lazy loads” in Go?
>
Not that I can see but it would be very useful in the case of a GUI running
in a separate goroutine to the one creating/updating data being displayed
by the
the abstract origin. In this ELF/DWARF
> file, it is likely that the entry is in a different compile unit, meaning
> that the line reader is referring to the wrong line table.
>
> With a bit more care, I'm now using the correct line reader and the
> problem no longer occurs.
>
>
&g
The blog is very interesting. However, I can't see how to re-implement this
in Go with only the syscall package or the golang.org/x/sys/windows
package. It needs the functionality of C++ freopen(), which as far as I can
tell is not possible with the WinAPI - From what I can gather, ReOpen()
ay you don't need 2
> binaries, however you'd need to tail the file, which seems to me better
> than 2 binaries.
>
> Best,
> Anderson
>
>
> On Friday, April 29, 2022 at 2:47:06 PM UTC+2 stephen.t@gmail.com
> wrote:
>
>> You're right, it is a Wind
>
> On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com
> wrote:
>
>> Hello Alex. Thanks for your response.
>>
>> On Fri, Apr 29, 2022 at 9:34 AM brainman wrote:
>>
>>> Once windows executable is built, go has no control over ho
ext for this is an application that has a GUI by default and
optionally, a terminal interface (using stdout).
I'm not a Windows person and I'm sorry if this is a dumb question but this
is a complete mystery to me. Do I really need two separate binaries?
On Monday, April 25, 2022 at 9:48:18 AM UTC+1
Hello,
I'm cross-compiling my Go application to Windows and I'm having difficulty
understanding how Windows interacts with stdout.
I'm compiling the Windows binary with the "-H=windowsgui" LD flag. This
works great but I've found that the program will never print to stdout,
even if the
der is referring to the wrong line table.
With a bit more care, I'm now using the correct line reader and the problem
no longer occurs.
Thanks for the help.
On Sunday, February 13, 2022 at 10:59:44 PM UTC stephen.t....@gmail.com
wrote:
> Okay. I've attached a text file showing the r
m I misunderstanding the relationship between AttrDeclFile and
LineReader.Files(), is there some other way of accessing the file array, or
has something gone horribly wrong?
Regards, Steve.
On Monday, February 7, 2022 at 3:50:07 PM UTC stephen.t....@gmail.com wrote:
> That does help.
thub.com/golang/proposal/blob/master/design/22080-dwarf-inlining.md#example
>
> which describes the changes made to the compiler to add DWARF inlining
> support. HTH.
>
> Thanks, Than
>
>
> On Sat, Feb 5, 2022 at 4:44 AM stephen.t....@gmail.com <
> stephen.t@gmail.co
Reader.SeekPC() is useful. Thanks. The problem was due to my
misunderstanding of how inlined functions are represented in the DWARF
data.
I've solved it now. Thanks again.
On Saturday, February 5, 2022 at 6:49:06 PM UTC Ian Lance Taylor wrote:
> On Sat, Feb 5, 2022 at 1:45 AM stephe
(This is possibly off-topic)
I'm trying to decode the DWARF data in an ELF binary and I'm not sure how
to handle functions.
I'm using the elf/dwarf package in the Go standard library and successfully
using it to identify compile units and source files and also to find line
entries for an
Hello,
I've been using modules for a while now and I thought I understood them but
it seems that I do not.
I have a project that is tagged at the latest version as v0.14
I have another project that uses the first project but I cannot get it to
use the latest version. The latest version it
Hello,
I have a moderately large Go project that performs fine on my development
machine. However when compiled for WASM the performance drops off
significantly. I'm hoping someone can help me understand why.
For comparison purposes, on my hardware, the emulator will run uncapped at
a
TL;DR, don't do that. See the issue for more details.
>
>
> On Thursday, November 19, 2020 at 12:59:32 PM UTC-8 ren...@ix.netcom.com
> wrote:
>
>> Based on the OP it is occurring with 1.13,14,15
>>
>> > On Nov 19, 2020, at 2:19 PM, Ian Lance Taylor
>>
Hello,
I have a reasonably sized project that produces executables that have
ballooned in size between two relatively simple commits.
I've tested with three compiler versions and in each case the executable
size is significantly larger in one case than the other.
The changes between the two
17 matches
Mail list logo
