Category Archives: Uncategorized
20K + hits on Technobeans…
Just another milestone that proves Technobeans is meeting its objective of making community aware of technologies and helping them solve their problem.. Thanks 
Performance for testing memberships: list vs tuples vs sets
Sets in Python are often used for two purposes:
1. Removing the duplicate entries in a collection
2. For membership testing.
By membership, here we mean to find existence of element in a collection
The focus of this post is to evaluate performance of list, tuple and set data structures with respect to each other on the basis of membership testing.
How do I do it? Well, some code, some data collection and some analysis
from datetime import datetime
listA = range(10000000)
setA = set(listA)
tupA = tuple(listA)
def calc(data, type):
start = datetime.now()
if data in type:
print ""
end = datetime.now()
print end-start
calc(9999, listA)
calc(9999, tupA)
calc(9999, setA)
Below is the average of 10 iterations for the time taken by lists/tuples and sets for testing membership of 9999, 99999, 999999 in 10000000
| Search 9999 in 10000000 | ||
| list | tuple | set |
| 0.8 | 0.8 | 1.9 |
| Search 99999 in 10000000 | ||
| list | tuple | set |
| 2.6 | 2.8 | 1.7 |
| Search 999999 in 10000000 | ||
| list | tuple | set |
| 21.4 | 21.6 | 0.8 |
Conclusions
1. for testing membership of elements at the beginning of the collection, lists or tuples perform more than 100% better than sets
2. As soon as you start testing membership of elements that are in the middle or end of the collection, sets perform 40% – 1800% better than lists or tuples
You now have a fair idea why you should think of using sets for large collections…
Note
Hardware I used: windows 7, x64, 4GB RAM
Python version: 2.7.2
Advocating Code Review for Testers
Author: Chetan Giridhar
Published at: testingexperience, September 2010 Edition
image courtesy: http://testingexperience.com
According to Wikipedia, “Code review is systematic examination(often as peer review) of computer source code intended to find andfix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers‘ skills.”
Code Review has been a good practice featuring as an important part of the software development life cycle. Not only has the practice helped in finding or rather preventing critical defects early in the cycle (thereby reducing the bug fixing costs), but it has also been instrumental in improving developers’ knowledge and build exposure to the other components of the software.
However, have we ever seen QA professionals participating actively in code reviews? With Quality Assurance being a proactive process aimed at preventing defects, wouldn’t code review feature in the QA realm as well? Would it make sense to make code reviews an integral part of QA processes? Are there any risks associated with doing so?
This article aims at breaking the myth, or at least triggering a thought process, of why testers couldn’t be or shouldn’t be an imperative part of code reviews. During the course of this article, the author substantiates the merits of the thought and also throws light on the flip side of it. At the end, the author hopes that the readers (independent of their role in the software industry) give this philosophy sufficient thought and evaluate whether including testers in code reviews would be beneficial as a process and if it would be helpful for their team context or not.
Click to download the article - Advocating Code Review For Testers
