November 14, 2011

New Version of Anti-patterns Parser

I have a new version of the anti-patterns parser.

New Features
1. Rules Library: Anti-patterns rules have been moved out of the parser to an external file. Users can therefore add, modify and delete rules to the library without the inconvenience of having to touch the parser. This can also help individuals customize and eliminate false negatives that the parser usually catches (while being generic).

2. Hints: The old parser could only identify anti-patterns in Perl and Shell scripts. This was difficult for users new to the tool and especially for non-experts of Perl and Shell to understand and act upon the output. The new version provides one or more hints to enable fixing each anti-pattern (partly based on Programming Anti-patterns in Perl and Programming Anti-patterns in Shell). For a complete idea, however, the user may still have to refer the and scripts.

3. Level: Each anti-pattern also has a level associated with it -- IGNORE, WARN, ERROR. This is currently not being used by the parser itself, but it will hopefully help users to parse for anti-patterns in severity levels of their interest.

The new version also benefits from a few bug fixes, dead code removals, and miscellaneous improvements. Most of all, I finally learnt how to apply Perl's map and nested map, yay! I think the parser is more readable now, and I hope I haven't abused map. You tell me.

An anti-pattern rule can be defined using the keywords LANG, REGEX, HINT and LEVEL. Lines not starting with a keyword are ignored as comments, and anti-patterns should be separated by comments. LANG can either be "perl" or "shell". REGEX is a Perl regular expression. LANG and REGEX are required keywords. HINT and LEVEL are optional. The anti-patterns parser doesn't try to check for errors in the rules library, so the user will have to take care of that aspect.

Because of the addition of a rules library, and the option for users to use their own custom library, the parser now needs an extra input.
$ ./  file|dir|pkg

I have deleted all previous files related to anti-patterns. You can download the latest zipped folder here. It contains updated versions of,, and a new anti-patterns.lib. I am inexplicably hesitant about hosting this on Github. Please note that this is being released under MIT License, thanks to the approval of Symantec Corporation.

The feature of suggesting one or more hints comes at a price: performance. Because the parser should now check against every anti-pattern, and not break immediately after finding the first one, the parser is several times slower than the old version. This is noticeable while running the parser on a large directory or package, though it may not be while running on a file. By the time I figure out a solution to this (please help!), if you want to disable multiple hints (and are satisfied by just one hint), comment out the only "else" blocks that are part of parsePerl and parseShell subroutines.

The new parser hasn't yet been extensively tested, so there are bound to be bugs. Feel free to report bugs, and suggest new anti-patterns and features. Thank you in advance.

All credit for this release goes to Rocky Ren, a Symantec colleague. Many people have made feature requests, but Rocky went several steps further. He not only requested specific features, but also suggested how those features could be implemented -- using his own prototype -- making me guilty enough to include his suggestions. The rules file and its format are also entirely his idea. Many thanks to Rocky.

June 23, 2011

The Fuss About Programming Anti-patterns

Andrew Koenig started talking about programming anti-patterns more than 15 years ago. It probably never got as popular as it should have been because it addresses the mistakes in syntactically correct software and we can imagine that the number of wrong ways to do something might be an inexhaustible list compared to the right ways. I still think it is a useful concept. Even experts are known to make mistakes, all the time. Majority of the performance enhancements I came across in my limited experience in fact fall under bug fixes, whether it is because the solution wasn't designed well enough or wasn't implemented well enough.

Given a system, improving its performance in general corresponds to improving the performance of its slowest component. This needs the identification of the slowest component to begin with using profiling at some level. Profiling, being time-consuming, isn't always done until a system (an operation on the system) feels poorly performant, and such feelings get mixed up and get slower to perceive as the thickness (complexity) of a system increases.

For this reason I like the approach of checking for known programming anti-patterns using static code analysis. Static code analysis may get slower than build times, but is faster than test suite execution on built images. For now. The day the list of anti-patterns grows infinitely long, and along with it the static code analysis cycle time, the approach won't be feasible (though tiering of anti-patterns based on severity and history of occurrences seems promising).

Hence my interest in static code analyzers like Coverity and FindBugs, though I am yet to explore them well enough to actually know them. I am not aware of any major work along similar lines for Shell and Perl. I think it's worth exploring because there's a significant amount of software written in them (definitely in Symantec Corporation) and they're already slower than compiled languages.

Shell Scripts
The famous todo software is fully written in Bash. It has a lot of anti-patterns, a few of them being various usages of "echo | grep", "echo | sed", "echo | tr" itself. The longest piping anti-pattern in is of the form: "echo | sed | eval sort | sed | awk | sed | eval cat". It takes a list of todo items (echo), pads them appropriately with leading zeroes (sed), sorts them (eval sort), color codes the done items (sed), does something more related to color coding (awk), nullifies a few strings (sed), and then gets the final list (eval cat usually). Doesn't seem like the most natural way to do. If nothing, and if my superficial understanding isn't totally off, all the seds can be merged into the awk.

The Shell scripts that are part of the Cygwin installation on my computer have over a hundred anti-patterns of type "echo | sed" alone, and another hundred of "expr", without having all the packages. Bash Completion is one of the packages which might benefit significantly from fixing Shell anti-patterns, and it might translate into better response times. e.g. Command completion for "gcc --" with gcc v3.4.4-999 and bash-completion v1.3-1 creates 12 new processes, 6 of them due to a sed, sort and tr and their prerequisite bashes.

Perl Scripts
Fedora users will be familiar with dvd::rip, largely written in Perl. Even if one-tenth of its $command lines refer to Unix commands, they account a large number of anti-patterns. I'm not familiar with the command-line utilities related to multimedia, but there seem to be several avoidable usages of "cd", "convert", "echo", "ffmpeg", "ls", "mkdir", "rm", "umask", "which". (I've not gone through the source code, but glanced at the parsed code -- which I'll soon come to -- so I'm likely to be mistaken.)

On Solaris, the SUNWwebminu package (11.10.0 version that shipped with Solaris 10) has a surprising number and a wide variety of Perl anti-patterns using -- cat, chown, cd, cp, echo, find, grep, hostname, mv, ps, pwd, rm, rsh, sed, ssh, uname -- you name it. It could be the package that benefits the most from an overhaul in this direction.

The above mentions are only examples of programming anti-patterns out there in the vast universe of software that is being written, shipped, used. That is understandably because even experts are known to make mistakes, all the time. What we need to work on are mechanisms that can minimize those.

Below is a table of counts of common Unix commands found in scripts across various OS installations that I had access to. They are incomplete and likely full of false negatives, and the OSs were not full installations. I'm sure you understand my preference to not hit you with the versions, package names, their versions, etc. They don't mean much. They don't mean nothing either.

AIX PerlAIX ShellCygwin PerlCygwin ShellHPUX PerlHPUX ShellRHEL PerlRHEL ShellSolaris PerlSolaris Shell
Total Files2880Total Files1832Total Files2361Total Files1563Total Files7630Total Files7533Total Files1262Total Files2518Total Files5600Total Files5271
Size (MB)27Size (MB)13.5Size (MB)25Size (MB)8.5Size (MB)57.75Size (MB)84.25Size (MB)11.5Size (MB)13Size (MB)28.25Size (MB)20.5

Anti-patterns Parser
Symantec Corporation gave me permission to share this study with the community. Here I am with a hope to widen this discussion and learn something. As part of it, is a dirty parser that I wrote and extensively used along the way, and somehow embarrassed of. I'm sharing it only to convey a better idea of how easy it is to catch some of the programming anti-patterns. Before using it, understand that the parser is very incomplete, incorrect (defined how?), without any warranties or guarantees, and all that cal. I won't even recommend using it, but do take a look.

From all the code that I've read so far, I can see this barely scratches the surface. Apart from continuing to find and add programming anti-patterns in Shell and Perl, my next steps are to move on to Java and C in line with my personal and company interests. Please point me in possible directions and reach out to me if you share my interests.

June 10, 2011

Programming Anti-patterns in Perl

I will spare you with another round of the first half of this post and jump straight to the table of anti-patterns and alternatives in Perl. Check out for detailed examples. These barely scratch the surface for a rich language like Perl, whose motto itself is TMTOWTDI. My Perl knowledge is still amateurish and these concentrate almost exclusively on the "Accessing memory << Calling a function << Forking a process" guideline. This might be useful for anybody switching from Shell to Perl. So I hope you'll have a lot more to contribute.

30th June, 2011: TimeRatio is the ratio of time taken by Alternative to that by Anti-pattern, as taken from two different trials, using Perl 5.8 on Solaris 10 (Sun T5120). I hope these time ratios will highlight better why especially some of the anti-patterns are to be avoided. My suggestion is to not take these numbers on face value.

awkopen, split, close0.780.79
catopen, close28.4828.72
cpuse File::Copy "cp"1.851.87
chmodchmod (Perl)335.75343.30
finduse File::Find0.550.55
grepopen, grep (Perl), close2.562.57
headopen, break, close42.1242.60
hostnameuse Sys::Hostname10361.9410451.25
killkill (Perl)55.0450.84
ln -ssymlink1010.70995.73
lsopendir, closedir32.8724.17
mkdirmkdir (Perl)13.2112.93
mkdir -puse File::Path9.859.87
mvuse File::Copy "move"32.5332.65
pinguse Net::Ping1.040.65
ps -elfuse Proc::ProcessTable3.843.84
rmdirrmdir (Perl)20.1319.88
rm -ruse File::Path9.009.02
sedopen, s/find/replace/, close25.5425.76
sleepsleep (Perl)2825.822824.30
sortopen, sort (Perl), close4.314.18
tailopen, close2.712.69
touchopen, close65.4165.41
umaskumask (Perl)7749.437742.40
unameuse Config13662.5613652.62
uniqopen, unless seen, close2.332.35
wc -lopen, close6.796.82

June 09, 2011

Programming Anti-patterns in Shell Scripts

How to create a new file from inside a Shell script?
touch newfile1
# OR
echo > newfile2
: > newfile3

Which of these is better? "touch" is a Unix command, "echo" and ":" (No-Op) are built-in Shell functions. If you "time" the above operations, you will see that the first is very much slower than the second is slightly slower than the third. I'll spare you the reasons.

In my opinion this is a difference that is not highlighted enough. I have seen thousands of lines of "shell script" which are indistinguishable from "one-liners" typed at the command-line. The reason anyone writes something inside a script and not at the command-line is the assumption that it will be used more than once, and that alone is reason enough for "efficiency" to be a criterion. Nothing slows down a script like a bunch of one-liners in it. And scripts are slow to start with.

Contrary to popular belief a Shell script is not a file with a bunch of lines each with some combination of Unix commands (called "commands text"). Shells are like all other languagues, with many useful features. I have a few unoriginal guidelines for writing scripts (Shell, Perl, Batch, ...):
1. Use environment and internal variables. (Like $HOSTNAME, $MACHTYPE, $PWD in Bash.)
2. Use built-ins and libraries. (Shells have a type command to verify the existence of an eqivalent built-in.)
3. Self-parse text. (Shells have built-in string manipulation and substring extraction functions with regexp support.)
4. Combine operations. (Many commands, internal and external, can take multiple arguments.)
5. Check fork rampage and /dev/null redirections. (They are used far more than necessary.)
6. Refer the manual. (Again.)

Moving on to the more useful part. Below is a table containing many anti-patterns that can be found -- I came across each of them numerous times -- in Shell scripts along with suggested alternatives. It is a work in progress. I hope you find it useful and I hope you will help add more rows ot it. Check out for detailed examples of the anti-patterns and alternatives. It should work with various other Shells as well with minor changes. Combinations of these anti-patterns are common, and alternatives aren't necessarily the most efficient, nor are they efficient all the time.

30th June, 2011: TimeRatio is the ratio of time taken by Alternative to that by Anti-pattern, as taken from two different trials, using Korn Shell 93 (dtksh) on Solaris 10 (Sun T5120). I hope these time ratios will highlight better why especially some of the anti-patterns are to be avoided. My suggestion is to not take these numbers on face value.

awk '{print}'read -A1.311.32
awk | grepawk1.091.09
awk | sedawk1.531.53
awk | sortawk2.182.18
cat | awkawk1.11.1
cat | grepgrep1.381.36
cat | headhead21.5921.46
cat | readread1.451.47
cat | sedsed1.171.17
cat | tailtail1.61.5
cat |wcwc15.2115.45
echo | awk($string)212.72159.63
echo | cut($string)100.83100.25
echo | cut | cutsubstrings187.91185.18
echo | grepif [[ $string == regexp ]]381.61378.55
echo | sed${string/find/replace}341.36329.14
echo | wc -m${#string}161.39165.7
echo | wc -w($string); ${#array[*]}85.6985.9
grep | awkgrep1.071.07
grep | grepsed11.01
grep | sedsed1.021.03
grep | grep -vsed1.011
grep | wcgrep -c0.990.99
headread, break1.21.21
head | awkread -A, break66.7268.4
ls | awk(ls)1.041.23
sed | sedsed1.091.05
tail | awk(tail)1.481.44
wc | awk(wc)13.5311.67

June 07, 2011

Programming Anti-patterns

TMTOWTDI is often a trait of the problem that one is trying to solve, and not just the programming language being used. Solutions can be simple or complicated, efficient or inefficient and an invisible constraint of solving problems (implementing) is to find a solution that is in the neighborhood of simple and efficient. Internet helps in finding a solution that is popular or common, and not necessarily efficient.

When I started noticing lots of inefficient code and identified a few patterns across them, I embarked on a study of programming anti-patterns. The definition I follow is, "Commonly used inefficient programming practices to which better alternatives are known".

For my study I also need anti-patterns to be easily identifiable so that dummies like yours truly can identify them, for comparisons between anti-patterns and alternatives to be easily made, for static code analyzers to fish them out, and for changes to be relatively easy to implement. Bill Pugh once said (probably in this) that the goal of FindBugs is to find bugs that are one step away from compilers. My goal is similar, only my focus is on efficiency more than correctness. (There are other kinds of anti-patterns, most famously design anti-patterns, but my focus at present is on code efficiency itself.)

The problem of looking for a new anti-pattern (source) is non-trivial. A few guidelines that I am considering are:
1. Accessing memory << Calling a function << Forking a process: There are exceptions to this, but to my understanding it's mostly true. Smaller the operation that needs to be performed, larger the overhead of doing it in round-about methods. It's easier to check the forking of processes as explained earlier. Re-calling functions is apprently not very uncommon, but I'm yet to scratch the surface of calling functions vis-a-vis reusing their return values.
2. Legacy code: In my experience code is more often added to, and old code isn't as much "updated" as is "fixed". Resultantly, "legacy code" to a great extent contains code written ages ago. Languages on the other hand constantly evolve, and the things of interest here are newly introduced, say functions, that can do something better. (The first example that comes to my mind is the rampant presence of += for string concatenation in Java instead of StringBuffer or StringBuilder.)
3. n00bs: Bill Pugh mentioned in the same video that, not surprisingly, people new to a programming language are a great source of learning how not to do something (even though it is not syntactically wrong). I have personally seen this to be true. A trickier subset of this is anti-patterns brought in when one migrates from one programming language to another.

June 03, 2011

NewProcs: A High-level System Activity Indicator

Operating systems are fairly multi-tasking and processes are their major, most visible components. In line with Heisenberg's Uncertainty Principle, which I see everywhere these days, observing processes can be more accurate than observing any smaller components. In my job I mostly observe process-level behaviors; at least I begin there. Recently I started staring from one more level zoomed out -- the lifetime of a process -- and insensitively asking, "Should this process have been created?"

It's a question that is sometimes easy to decide, but not always. It is like an Age of Empires player asking herself, "Should I create a new villager?". It depends on the tasks pending, the resources available, the world and the neighborhood into which he might be born, the greater purpose his long-term life could serve, and even the nature of the creator.

One small step towards deciding this is the knowledge of process lifetimes, their births and deaths, and so a measurement that I now routinely take is "NewProcs". On Windows, Process Monitor through filters "Operation is Process Create" and "Operation is Process Exit" does a beautiful job of this. On Solaris the following DTrace one-liner will do: dtrace -qn 'proc:::exec-success, proc:::exit {printf("%d\t%d\t%Y\t%s\n", pid, ppid, walltimestamp, curpsinfo->pr_psargs)}'. On OSs with SystemTap the following one-liner will do: stap forktracker.stp (the file should be located in the SystemTap examples directory). On Unix-based OSs, I have a feeling GNU Acct can serve as a workaround.

One major area that can take advantage of this is "scripts" - be they Batch scripts or Shell scripts or Perl scripts. Especially in enterprise software, perepheral operations like installations and configurations use a lot of scripts. I will try to elaborate on that in the near future.

The number of processes being created and killed itself isn't necessarily a good indicator, but the detailed list can occasionally throw a lot of light on the high-level system activity during various operations. Below are a few examples (naïve layman's curiosities):

1. On Windows 7 and Windows Server 2008 (probably Windows Vista as well), Explorer can navigate the calendar, connect to various networks, switch battery power plans, browse and search for various programs all without creating any new processes. However the Speakers/Headphones icon in the system tray needs to create a new process, SndVol, for any basic volume change operation.

2. Windows Media Player Network Sharing Service Configuration Application (wmpnscfg) is one inexplicable troll. It keeps appearing during scenarios where its existence isn't all that clear. e.g. Whenever one connects to some networks, several short-lived wmpnscfg processes get created. A disconnect is usually associated with another instance.

3. When one looks for the version of Google Chrome (at least with 11.0.696.71), the "About Google Chrome" dialog creates a GoogleUpdateOnDemand process which goes on to create two more processes: GoogleUpdate /ondemand, GoogleUpdate -Embedding. The browser also has a nice feature of Gmail notifications. Unlike notifications from Microsoft Office Outlook, each Gmail notification comes through a separate procress (chrome -type=renderer, the tab process). Google Chrome is known to be a "multi-processed" application for reasons of stability and security, but.

Cygwin (and MinGW) earnestly takes up its share of process creation as explained here. I'm sure everyone has their reasons, but high birth rates and infant mortality rates always concern me. Should these processes have been created? What do you think?

June 01, 2011

vxperf2 Examples

1st July, 2011: GitHub is the new home of vxperf2. Download vxperf2.

Let us take a sar log which was first collected as a binary using -A and -o options and then dumped as a text database using -A and -f options. The log is almost in a text database format, with several tables in it. It has one OS-specific header and many "Average:" lines that are not of our interest because we're interested in subsets of the duration in which the logging was done, and not the entire duration.

So we first convert the log to a table using from the command-line or log2db module (modifySysstat subroutine) inside a Perl script. sardb is the text database file that we'll use from here onwards.

Example 1
Suppose we want a summary of CPU utilization (just %usr, %sys), load averages (ldavg-1, ldavg-5, ldavg-15), faulting (fault/s, majflt/s) and context switching (cswch/s). Our rules file would be something like:

# rules1: Rules file for Example 1.
# Any line in the rules file that does not start with a keyword is ignored.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
# End of Example 1 rules file.

We get the results from sardb and rules1 using from the command-line or vxperf2 module (parseLogFile and applyRules subroutines) inside a Perl script. In the results directory, a summary.txt (name hardcoded) is created that contains one line each for %usr, %sys, ldavg-1, ldavg-5, ldavg-15, fault/s, majflt/s and cswch/s reporting their functions (currently min, max, sum, count and average).

Example 2
I glossed over one aspect of the CPU utilization summary in the previous example, which is that -A option gave per-processor statistics as well as an "all", and we went ahead with clubbing them together. It isn't exactly a mistake in this case, but suppose we do want to separate the per-processor statistics. Our rules file would be something like:

# rules2: Rules file for Example 2.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
# End of Example 2 rules file.

There can be only one z-axis rule, and only one field for it. vxperf2 takes the field following the z-axis keyword, and divides the CPU utilization table into sub-tables, one for each distinct value of "CPU". Along with all the lines of the previous summary.txt, the new file will now contain a few additional lines each for %usr and %sys, lines corresponding to the processors and "all".

Example 3
Suppose we want a couple of graphs, one for CPU utilization and one for load averages. Our rules file would be something like:

# rules3: Rules file for Example 3.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
plot: %usr %sys
plot: ldavg-1 ldavg-5 ldavg-15
# End of Example 3 rules file.

vxperf2 takes the fields following the plot keyword on one line and plots them using Gnuplot, naming it $field1-$field2-...-$fieldn.png. As many images as there are plot keywords in the rules file are created. The CPU utilization image will have per-processor and "all" plots because of the z-axis keyword. In this particular case, however, the second image will be empty as there are no per-processor load averages. (Instead, dropping the z-axis keyword will allow plotting of load averages. A limitation.)

Example 4
In the %usr-%sys.png created in the above examples, there are per-processor %usr plots and one "all", and similarly for %sys plots. What if we are interested in timelines of only a few of the processors, or not interested in "all"? A similar question of more significance would be when looking into block device or process-level statistics. Our rules file would be something like:

# rules4: Rules file for Example 4.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
plot: %usr %sys
only: 0 all
# End of Example 4 rules file.

There can be only one only rule, and it makes sense only in the presence of a z-axis rule (z-axis has a field name and its corresponding values are a superset of only). vxperf2 this time only plots %usr and %sys corresponding to processor 0 and "all", though it summarizes for other values of CPU as well.

Example 5
It is common to start logging a few intervals before the period of interest, and to end logging a few intervals after. Suppose we want to ignore the first 10 intervals, and then we are only interested in the next 100 intervals. Our rules file would be something like:

# rules5: Rules file for Example 5.
y-axis: %usr %sys ldavg-1 ldavg-5 ldavg-15 fault/s majflt/s cswch/s
z-axis: CPU
plot: %usr %sys
only: 0 all
offset: 10
points: 100
# End of Example 5 rules file.

vxperf2 does what it did exactly in the previous example, except that it does it over a subset starting at the 11th reading and ending at the 110th.

Simple enough?

I mentioned a couple of limitations above and there are many others, most of which I discover only when using vxperf2, and there are often workarounds to these. vxperf2 module exposes two subroutines parseLogFile and applyRules. parseLogFile parses a text database and stores it as an in-memory database. applyRules parses a rules file and applies the rules to multiple databases at once. One parseLogFile invocation per log file, followed by one applyRules invocation per rules file.

May 30, 2011

Use vxperf2 to Analyze Text Databases

1st July, 2011: GitHub is the new home of vxperf2. Download vxperf2.

In my job I daily have to deal with many different kinds of logs, mostly generated by OS monitoring utilities, and I never found a single tool that summarizes and visualizes data from all those logs. e.g. Spreadsheets are great for typeperf logs on Windows, ksar for sar logs on Linux, and Esxplot for esxtop logs on ESX. But I don't know of one tool that works well for all of them.

I initially wrote a Shell-based tool called plotmon to extract, summarize, and visualize fields (using Gnuplot) of specific interest from a few particular logs (mainly pidstat, sar, top). I then ported it to Perl for better performance. Its drawback was that it handled each log on a case-by-case basis. As the number of OSs (ESX, RHEL, Solaris, Windows), the number of OS monitoring utilties (esxtop, iostat, mpstat, netstat, pidstat, prstat, sar, typeperf, vmstat), and fields of interest that I occasionally had to come across increased, naive plotmon was no longer viable. So I discarded it and picked vxperf2.

vxperf2 is a Perl-based tool that I wrote, maintain, and use a lot for "analyzing" logs. vxperf2 can process any log as long as it is a text database. (Text database: Imagine an SQL database with several different tables in it. For each of the tables, fire "select * from ", and redirect all output to a single text file. That text file is a text database.)

While even Unix top output on the same OS differ in their formats when using two different toprcs, they and all other logs generated by all OS monitoring utilities (et al) can be trivially modified into text databases through minor changes (mostly reformatting). So the way to process any log is through two steps: first modify the log into a text database (simple though log-specific formatting: log2db) and then use vxperf2 on the text database.

vxperf2 takes a rules file containing six keywords: y-axis, z-axis, plot, only, offset, points. y-axis is about the fields of interest (columns of a table) that are to be summarized, z-axis is the field each of whose values has a different meaning (e.g. PID), plot is about the list of fields that are to be plotted together (against timeline), only is about the z-axis values at which previously specified plots are to be plotted, offset is about the number of readings from the beginning that are to be ignored, points is about the number of readings from the offset that are to be considered. If you read the documentation and try to use the tool you'll get a fair idea of the need for these keywords and the flexibility they provide. You will see that vxperf2 can summarize (basic functions count, max, min, sum, avg), visualize (plot), navigate (skip data points), zoom in (consider a subset of data points) and compare (within and across logs) any specified subset of fields of interest. You can also check out the "examples" directory in the tarball for examples of logs, their equivalent text databases, and rules files.

I've been using this tool heavily for most of my work involving log analysis, and so are a few others in my group. Symantec Corporation gave me the permission to release it as open source almost four months ago. The idea of getting it through CPAN or creating a repository on Github has been putting me off since then. I guess this is a place as good as any to start sharing vxperf2 with the outside world. I'm releasing this under GNU GPL today. The tarball contains no malware, and one 14-word README file that should get you started. Ask me if you have any doubts.

My knowledge of Perl is amateurish at best, and this project was one of the major ways in which I learnt some basics, especially two-dimensional data structures in Perl. (vxperf2 uses an array of arrays, an array of hashes, a hash of arrays, and a hash of hashes.) There are bound to be a bunch of bugs, so don't hesitate to holler. On the other hand, development of new features (each keyword, e.g.) has been entirely driven by my immediate needs, so your wishes may not necessaribly be granted immediately (by me).