Jump to content
Mike Torrettinni

Refactoring Enum to string using enum helpers

Recommended Posts

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 by Tom F
  • Thanks 1

Share this post


Link to post
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?

 

 

Share this post


Link to post
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? 

Share this post


Link to post

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. 

Share this post


Link to post
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. 

  • Thanks 1

Share this post


Link to post
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.

  • Like 2

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×