![]() ![]() UsrTimeEnd := time.Unix(r.Utime.Sec, int64(r.Utime.Usec*1000)) _ = syscall.Getrusage(syscall.RUSAGE_THREAD, &r) UsrTimeStart := time.Unix(r.Utime.Sec, int64(r.Utime.Usec*1000)) _ := syscall.Getrusage(syscall.RUSAGE_THREAD, &r) Payload, _ := ioutil.ReadFile("test.txt")Ĭh := make(chan time.Duration, nbrThreads) Pattern := pcre.MustCompile(`.`, pcre.MULTILINE|pcre.DOTALL) "/glenn-brown/golang-pkg-pcre/src/pkg/pcre" So that measure might be the right one to use. Thanks a lot, that looks like what I need indeed… probably RUSAGE_THREAD is the way to go, but I’ll make some tests, because - if I understood cgo correctly - cgo calls themselves don’t run as lightweight goroutines, but “occupy” a full system thread. Maybe the sleep is not a good task to measure. I’m not sure if the values you get this way are pertinent. I noticed a big variation in the values which doesn’t make much sense. UsrTimeEnd := time.Unix(r.Utime.Sec, r.Utime.Usec*1000)įmt.Println("Sys time:", sysTimeEnd.Sub(sysTimeStart))įmt.Println("Usr time:", usrTimeEnd.Sub(usrTimeStart)) SysTimeEnd := time.Unix(r.Stime.Sec, r.Stime.Usec*1000) UsrTimeStart := time.Unix(r.Utime.Sec, r.Utime.Usec*1000)Įrr = syscall.Getrusage(syscall.RUSAGE_SELF, &r) SysTimeStart := time.Unix(r.Stime.Sec, r.Stime.Usec*1000) could be as well syscall.RUSAGE_THREAD, no sure if it would make senseĮrr := syscall.Getrusage(syscall.RUSAGE_SELF, &r) To compute the time spent by the CPU to execute some task you could inspire you of the following code: package main But there is the syscall.Getrusage() function that fills a struct with values including system and user times. To compute CPU usage, there is unfortunately no equivalent of the C clock function. Logging execution time to trace down the input data causing problems looks like a good alternative strategy. Unfortunately, there is no way to abort the execution of a long cgo function call, which is what you want. All I found on Google at some point tells you to use pprof - which I think would be overkill for this case, and would not give me the information grouped the way I’d need it but maybe I’m missing something? Is there a way to get this information, or maybe at least for the cgo call itself? Measuring thread times would not work neither, as go routines are lightweight (not sure however about cgo calls). This works quite well, but of course wallclock time is not optimal in case of a concurrent program the actual CPU time used by the current goroutine would be much better. sorted and summed after tge search terms), so I started by simply measure wallclock times before and after these regex calls. I would prefer not using Go’s pprof (I don’t think I get the data I need out of it, i.e. Basically this would mean to stop the execution of a goroutine from another one, which afaik is not possible but maybe there is some way to solve the issue for an external cgo routine that went havoc?Īn alternative solution would be to at least log execution times of these calls, and also sort them such that I can see what search term caused problems on what data. One problem is that the execution of the C library call often takes a very long time, so I’m wondering if there’s a possibility to time-limit these calls. In my project, hundreds of threads are using this library concurrently. So I’m using /glenn-brown/golang-pkg-pcre/src/pkg/pcre, which is a wrapper around the Unix pcre library (using cgo). This is about a project that needs to check regular expressions in Perl style (including lokaheads etc, which are not supported by Go’s standard regexp). ![]() I got 2 problems related to the same task (hence I only post it once). ![]()
0 Comments
Leave a Reply. |