On 24 October 2013 22:34, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote: > I understand your desire for things to be fast, but let me just re-iterate my view > that for this kind of jobs, performance is completely secondary. Memory > debugging and analysis is an off-line, laboratory task. In my opinion, > performance should not be driving the design of a module like this. And in > particular, it should not be the only reason to write code in C that could > just as well be written in .py. > This is a lorry. A lorry is for moving refrigerators, on those rare occasions when > you need to have refrigerators moved. It doesn't need go-faster-stripes. > > Well, I think I've made my point on this amply clear now, in this email and the > previous, so I won't dwell on it further. Not everything is a PC that you can just add more memory to (or switch to a lab server with the same CPU architecture but more RAM). If Victor were only interested in analysing x86[_64] software, I'd agree with you, but embedded scenarios don't always offer that freedom to do resource consumption analysis on a more powerful system. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4