Sponsored Content
Full Discussion: Which is more expensive ?
Top Forums Programming Which is more expensive ? Post 302131738 by reborg on Monday 13th of August 2007 12:35:54 PM
Old 08-13-2007
I don't think there would be any real difference here, there might me a very marginal improvement in the second case due to the number of comparison you are doing, but would expect that to be marginal. You are after all incrementing the same number of times in both cases anc calling close() the same number of time.

Just curious, is this shutdown code or is it after forking that you are closing the open fds?
 

2 More Discussions You Might Find Interesting

1. Programming

calling pthread_self (on ubuntu), expensive?

Hi all, Is anyone aware of what operations are involved when a call to pthread_self() is made, obtaining the unique thread ID on a Ubuntu system (or even any Linux flavour)? Specifically, to retrieve the thread id, is there any locking required or atomic operations? I'm building an... (11 Replies)
Discussion started by: gorga
11 Replies

2. What is on Your Mind?

Very Expensive Running Shoes

You really should not need one third of the entire US budget to buy a pair of running shoes... even if they are name brand. What have these guys been smoking? It reminds me of the old joke... Customer: At those prices you aren't going to sell many shoes. Salesman: Ah, but all we need to do is... (4 Replies)
Discussion started by: Perderabo
4 Replies
Perl::Critic::Policy::InputOutput::RequireBriefOpen(3pm)User Contributed Perl DocumentatioPerl::Critic::Policy::InputOutput::RequireBriefOpen(3pm)

NAME
Perl::Critic::Policy::InputOutput::RequireBriefOpen - Close filehandles as soon as possible after opening them. AFFILIATION
This Policy is part of the core Perl::Critic distribution. DESCRIPTION
One way that production systems fail unexpectedly is by running out of filehandles. Filehandles are a finite resource on every operating system that I'm aware of, and running out of them is virtually impossible to recover from. The solution is to not run out in the first place. What causes programs to run out of filehandles? Usually, it's leaks: you open a filehandle and forget to close it, or just wait a really long time before closing it. This problem is rarely exposed by test systems, because the tests rarely run long enough or have enough load to hit the filehandle limit. So, the best way to avoid the problem is 1) always close all filehandles that you open and 2) close them as soon as is practical. This policy takes note of calls to "open()" where there is no matching "close()" call within "N" lines of code. If you really need to do a lot of processing on an open filehandle, then you can move that processing to another method like this: sub process_data_file { my ($self, $filename) = @_; open my $fh, '<', $filename or croak 'Failed to read datafile ' . $filename . '; ' . $OS_ERROR; $self->_parse_input_data($fh); close $fh; return; } sub _parse_input_data { my ($self, $fh) = @_; while (my $line = <$fh>) { ... } return; } As a special case, this policy also allows code to return the filehandle after the "open" instead of closing it. Just like the close, however, that "return" has to be within the right number of lines. From there, you're on your own to figure out whether the code is promptly closing the filehandle. The STDIN, STDOUT, and STDERR handles are exempt from this policy. CONFIGURATION
This policy allows "close()" invocations to be up to "N" lines after their corresponding "open()" calls, where "N" defaults to 9. You can override this to set it to a different number with the "lines" setting. To do this, put entries in a .perlcriticrc file like this: [InputOutput::RequireBriefOpen] lines = 5 CAVEATS
"IO::File->new" This policy only looks for explicit "open" calls. It does not detect calls to "CORE::open" or "IO::File->new" or the like. Is it the right lexical? We don't currently check for redeclared filehandles. So the following code is false negative, for example, because the outer scoped filehandle is not closed: open my $fh, '<', $file1 or croak; if (open my $fh, '<', $file2) { print <$fh>; close $fh; } This is a contrived example, but it isn't uncommon for people to use $fh for the name of the filehandle every time. Perhaps it's time to think of better variable names... CREDITS
Initial development of this policy was supported by a grant from the Perl Foundation. AUTHOR
Chris Dolan <cdolan@cpan.org> COPYRIGHT
Copyright (c) 2007-2011 Chris Dolan. Many rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of this license can be found in the LICENSE file included with this module perl v5.14.2 2012-06-07 Perl::Critic::Policy::InputOutput::RequireBriefOpen(3pm)
All times are GMT -4. The time now is 03:17 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy