http://qs1969.pair.com?node_id=11111129


in reply to Why not perl have raw/native type

If "frustratingly the program in Perl is still slow," it is unlikely that the true cause of it is dynamic data types. Profile your code to find out where and what the slowdown actually is. Do not assume. As Kernighan and Plauger said, "don't 'diddle' code to make it faster – find a better algorithm."

Replies are listed 'Best First'.
Re^2: Why not perl have raw/native type
by Anonymous Monk on Jan 07, 2020 at 18:15 UTC
    ... it is unlikely that the true cause of it is dynamic data types.

    Right. And you know this based on what? Nothing. You made it up, hoping to impress others with your "expertise". Give it a rest, mike. Please.

      Despite resembling an infamous user who said he would not come back, the anonymonk does have a point. While it is sometimes possible to find bottlenecks by a thorough understanding of the system, you are far more likely to get useful information from actual measurements — and those useful results may just be surprising even to an experienced programmer.

      In short, do not assume that perl's box/unbox routines (which should be very lightweight if you are reusing the container SVs) are the source of your performance problems — use profiling (at both Perl and C levels, so you can see the time spent in XS code) and then consider how to improve the running time of your program.

      Profiling is important. If you optimize one block of code to run in no time at all, but the program was only spending 1% of its time in that code, you have gained only 1%, but if you improve an algorithm to cut the running time of another block in half, but the program spent 70% of its time in that block, you have gained about 35%.

      A reply falls below the community's threshold of quality. You may see it by logging in.