3 ms·
The stuff I've used in recent months: - For Java, personally I like the netbeans profiler - Octave's built in profiler gets the job done: https://octave.or
by chunkyks 5y ago
The stuff I've used in recent months:
- For Java, personally I like the netbeans profiler
- Octave's built in profiler gets the job done: https://octave.org/doc/v6.2.0/Profiling.html
- I use JetBrain's tooling a lot.
- I like the profiler in Rider for VB.NET and C#
- The one in PyCharm is ... fine. Python profiling is ugly, PyCharm does a clean job handling it.
- For R, Rprof is ... fine: https://stat.ethz.ch/R-manual/R-devel/library/utils/html/Rprof.html
- STATA's built in profiler does as good a job as possible given it's a weird language
For various other things, where a profiler doesn't really exist per se:
- SAS can be configured to output runtime after each proc. There's no cost, you should do it
- SAS proc SQL has an undocumented _method flag: http://support.sas.com/techsup/technote/ts553.html
- Past "EXPLAIN QUERY PLAN", one of the tools I build ends up doing a simple visualisation of SQLite's explain query plan output for *every* query it runs. There's no way to *not* get that estimate
Those are the tools I can think of that I've used in the last few months.
- arthurcolle 5y agoI appreciate you taking the time to write this out. I'm curious about the lack of any mention of C/C++ tooling - I thought there are some mathematicians who write stuff in C/C++ and leverage libs like GNU SL (Scientific Library) etc. I've written a few custom pricers and needed to use those libs and they were pretty efficient, and didn't need to resort to anything crazy to run them in production. Curious if you ever find stuff written in those languages, as opposed to the gamut you just mention, which are classical "research tools" (language/IDE combinations that let you not need to think about the language specifically.
- chunkyks 5y agoI don't cross paths with a lot of C or C++ where profiling is a concern. I use gprof for that, but I haven't needed it in a few years. None of the folks I work with reach for C or C++ as a weapon in their quiver. I do cross paths with a fair bit of FORTRAN, but in my experience, generally if someone's writing FORTRAN, they already know the deal with performance. Fun fact: When I interviewed for my job [12 years ago], I interviewed with a guy using SQLite and FLTK in a C++ model. I'd been using SQLite and FLTK for some recent personal projects; in the interview, I solved a bunch of performance problems he'd been having for a couple years. I interviewed on Monday, and started working there two days later.