Refactoring Enum to string using enum helpers

[Tom F 83]

Mike,

You asked me what I meant by digging "too deeply."

 

Suppose you want to drive from New York City to San Francisco. It's about a 43-hour drive.

 

Suppose your friend says, "Oh, I can make your trip shorter. When you get to Chicago, there's a very long stoplight you'll probably have to sit at for two minutes waiting for it to turn green. But, to avoid the slowdown, I know a great detour. It'll save you about a minute. Turn left when you get to Main Street, and then turn right at the next street, go two blocks, and then turn right again and then turn at the next left. This will take you around the block, avoiding the stoplight delay, and then rejoin your original route to continue on your way to San Francisco." 

 

Would you take the detour?  The detour is faster than staying on the route with the long stoplight.

 

But is it enough faster for you to worry about? Is it enough faster to bother taking?  Is it enough faster to risk getting lost on the streets of Chicago? Is it enough faster to spend hours discussing on forums?

 

How much faster should the detour be before you're willing to take it?  How much risk can the detour add before you think to yourself, "I'm not going to take that detour." ???

 

In your code, you have no idea how long the trip is. You have no idea where the bottleneck slowdowns are. So, you have no idea if the proposed speedup will be significant.  And people here in the forum are telling you that your detour (new code) may be riskier (i.e. more difficult to maintain.)

 

Suppose your enum code is currently consuming a total of .0050 seconds every time a user clicks a certain button. Suppose you spend hours writing several versions of alternate code. Suppose your new code speeds up enum strings so that they're now TWICE AS FAST, so that processing enums only takes .0025 seconds.  Was it worth your time to work on this? 

 

What many of us have been saying to you here and elsewhere is that the revisions (detours) that you're suggesting to speed up your code are insignificant and may bring risk. You need to learn how to put your efforts where they will have the biggest impact on improving your code.  

 

The first rule is WRITE THE CLEANEST, MOST MAINTAINABLE CODE YOU CAN.

 

Then MEASURE your application with a performance monitor/profiler to identify places where it's slow.  A profiler will help you do this by showing you exactly where your code is spending its time.  

 

It's likely that the amount of time your current code is spending on enum strings is infinitesimal compared to everything else your code is doing. So even if you speed up the enum code, the speedup is likely to have no impact on your users.

Edited July 22, 2021 by Tom F

[Mike Torrettinni 198]

5 minutes ago, Tom F said:

The first rule is WRITE THE CLEANEST, MOST MAINTAINABLE CODE YOU CAN.

Thanks, very well written!

I think not using magic strings is first step towards your first rule, no?

 

 

[David Heffernan 2345]

4 minutes ago, Mike Torrettinni said:

Thanks, very well written!

I think not using magic strings is first step towards your first rule, no?

 

 

What's your definition of magic string? 

[Mike Torrettinni 198]

I just added Edit to my first post. I hope it gives more context on the purpose of this topic.

[David Heffernan 2345]

Nothing fundamentally wrong with your option 1, so long as that is the single place where those string literals are written. The array does have the useful benefit of leading to helpful compiler error when enums extended, as discussed. But yeah, none of these options is especially terrible. I'd actually rate option 2 as the worst. 

[Tom F 83]

20 minutes ago, Mike Torrettinni said:

Thanks, very well written!

I think not using magic strings is first step towards your first rule, no?

 

 

You're welcome.  It took a lot of time to write.  Good luck on your project. I'm headed back to coding.

See the earlier post by  @Stefan Glienke  about your #3 being less likely to fail in the future if you change the enum definition. 

[Bill Meyer 337]

1 hour ago, Tom F said:

Suppose your enum code is currently consuming a total of .0050 seconds every time a user clicks a certain button. Suppose you spend hours writing several versions of alternate code. Suppose your new code speeds up enum strings so that they're now TWICE AS FAST, so that processing enums only takes .0025 seconds.  Was it worth your time to work on this? 

Short answer is: Ordinary human response in workplace (not gaming) tends to be around 150-200mS. So in dealing with button click responses, the processing overhead in this situation is irrelevant.

[Mike Torrettinni 198]

If anybody wants to test GetEnumName vs other tests, this is Run4 I added to the original tests:

 

uses System.TypInfo;

procedure Run4;
var i, j: integer;
    vStr: string;
begin
  for i := 1 to cLoop do
    for j := 0 to Pred(cNoOfEnums) do
    begin
      vStr := '';
      vStr := GetEnumName(TypeInfo(TEnum), j);
    end;
end;

...
  vSW := TStopWatch.StartNew;
  Run4;
  vSW.Stop;
  Writeln('GetEnumName:       ' + vSW.ElapsedMilliseconds.ToString);

Perhaps anybody with 10.3 or 10.4 will see improvement in RTTI, versus my 10.2.3 version.

[Pieter Bas Hofstede 14]

FYI both release/win32

Fast RTTI in 10.4.2 🙂

 

[Mike Torrettinni 198]

4 minutes ago, Pieter Bas Hofstede said:

FYI both release/win32

Fast RTTI in 10.4.2 🙂

 

 

Thanks. Nice, very good to see this progress!