Refine your search:

Is there a performance difference between using the SEDCMD syntax in just props.conf versus using the older method which uses TRANSFORMS and calls a stanza in transforms.conf using REGEX?

asked 01 Dec '10, 06:50

DrewO's gravatar image

DrewO
1124
accept rate: 11%

Just to be clear, the SEDCMD and TRANSFORMS index-time transformations are not exact drop-in replacements for each other. For example, SEDCMD character substitution (like y/ABC/abc/), and repeating replacements (like s/eggs/spam/g) are things that can only be done using SEDCMD, but SEDCMD is limited to only modifying the _raw field. So in your question, I'm assuming that your are specifically asking about where these two approaches overlap (a single replace operation on the _raw field.) If this is incorrect, please update your question.

(01 Dec '10, 14:26) Lowell ♦

@Lowell yes that's what the student wanted to know. For one off replacements, like overwriting a credit card number/account code.

(02 Dec '10, 00:54) DrewO

One Answer:

For the particular case of s/one/two/ vs ^(.*?)one(.*)$ -> $1two$2, the former is possibly very slightly faster, but differences in the efficiencies of the regex used (e.g., using (.*?) vs (.*)) would probably enormously outweigh that. Note that it's actually not possible to use s/one/two/g (i.e., with the g flag) to replace multiple occurrences with TRANSFORMS.

link

answered 02 Dec '10, 07:47

gkanapathy's gravatar image

gkanapathy ♦
26.5k1622
accept rate: 42%

Post your answer
toggle preview

Follow this question

Log In to enable email subscriptions

RSS:

Answers

Answers + Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×148
×22

Asked: 01 Dec '10, 06:50

Seen: 415 times

Last updated: 02 Dec '10, 07:47

Copyright © 2005-2012 Splunk, Inc. All rights reserved.