# Anchor Pruning for Object Detection

Maxim Bonnaerens<EMAIL_ADDRESS>Matthias Freiberger Joni Dambre
IDLab-AIRO, Ghent University - imec, Gent, Oost Vlaanderen, Belgium

###### Abstract

This paper proposes anchor pruning for object detection in one-stage anchor-
based detectors. While pruning techniques are widely used to reduce the
computational cost of convolutional neural networks, they tend to focus on
optimizing the backbone networks where often most computations are. In this
work we demonstrate an additional pruning technique, specifically for object
detection: anchor pruning. With more efficient backbone networks and a growing
trend of deploying object detectors on embedded systems where post-processing
steps such as non-maximum suppression can be a bottleneck, the impact of the
anchors used in the detection head is becoming increasingly more important. In
this work, we show that many anchors in the object detection head can be
removed without any loss in accuracy. With additional retraining, anchor
pruning can even lead to improved accuracy. Extensive experiments on SSD and
MS COCO show that the detection head can be made up to 44% more efficient
while simultaneously increasing accuracy. Further experiments on RetinaNet and
PASCAL VOC show the general effectiveness of our approach. We also introduce
‘overanchorized’ models that can be used together with anchor pruning to
eliminate hyperparameters related to the initial shape of anchors. Code and
models are available at https://github.com/Mxbonn/anchor_pruning.

###### keywords:

###### MSC:

68T07, 68T45 Object Detection, Pruning, Real Time

††journal: Computer Vision and Image Understanding

Object detection is one of the most widely studied tasks in computer vision.
It requires not only predicting the class but also the exact location of each
object in an image. Object detection models are mainly categorized into two
categories based on whether detection happens in one or two stages. Two-stage
networks (Cai and Vasconcelos (2018); Girshick (2015); Ren et al. (2015)),
first run a regional proposal network (RPN) that produces class-agnostic
candidate object locations. These proposals are then used as input for a
second stage where the proposed object regions are classified and the location
of the object is refined. One-stage networks (Lin et al. (2017b); Liu et al.
(2016); Redmon and Farhadi (2017); Sermanet et al. (2013); Tan et al. (2020))
use a single convolutional neural network with a predefined set of default
anchors (i.e. an anchor associates a predefined size and aspect ratio to each
pixel at a feature map) of which the classes and location offsets are directly
predicted. While two-stage networks are generally the most accurate, one-stage
detectors tend to be more resource-efficient and are often the only choice to
run in real-time on resource-constrained devices, such as mobile platforms
(Huang et al. (2017)).

Many studies aimed at creating more efficient models for object detection have
been carried out in recent years. Most have achieved it through slimmer
backbone networks (e.g. MobileNet in SSDLite (Sandler et al. (2018))) or
compression techniques such as weight pruning and quantization (Deng et al.
(2020); Liu et al. (2018)). And while there has been some work on anchor-free
detectors (Law and Deng (2018); Tian et al. (2019)), most mainstream single-
shot detectors still use the same anchor-based approach (Lin et al. (2017b);
Redmon and Farhadi (2018); Tan et al. (2020)). As computational complexity in
the backbone network keeps shrinking, the importance of an efficient object
detection head, in which anchors are used to predict potential objects,
increases. The influence of these anchors on the computational cost of the
object detector is twofold. Firstly, the number of anchors an object detector
uses directly influences the size of the convolutional layers in the head of
the detection model. Secondly, all bounding boxes produced by those anchors
need to go through a non-maximum suppression (NMS) post-processing step to
determine the final detected objects. Previous studies on the speed/accuracy
trade-off for object detectors have shown that for small models, i.e. the ones
typically used in an embedded context, “NMS can take up the bulk of the
running time” (Huang et al. (2017)). While the exact running time of the post
processing step depends strongly on the used hardware, systematic assessments
(Verucchi et al. (2020); Cai et al. (2019)) have shown that the number of
detections coming out of an object detection network has a non-negligible
influence on the end-to-end inference time. Whereas traditional backbone
pruning techniques only influence part of the model inference time, anchor
pruning can reduce the running time of both the model inference and the post-
processing step.

In this paper we introduce a novel anchor pruning technique and evaluate its
effect on the accuracy and efficiency of one-stage anchor-based object
detection models. The main contributions of this work include:

(1) We propose an anchor pruning search algorithm that determines which key
anchors to remove and identifies several anchor configurations on the
accuracy/resources Pareto front, allowing model developers to trade accuracy
for performance when resources are constrained.

(2) We show that the accuracy of the proposed pruned models can be further
improved through fine-tuning or retraining from scratch. By removing well-
chosen anchors and retraining, it is possible to achieve both better
efficiency and accuracy compared to the unpruned baseline model.

(3) We introduce the concept of an ‘overanchorized’ model. By starting our
proposed anchor pruning approach on an object detector that has many closely
overlapping anchors, we show that we can avoid tuning hyperparameters related
to the initial shape of the anchors.

(4) We extensively benchmark our approach on the SSD and RetinaNet object
detectors on both the MS COCO and PASCAL VOC datasets. The results strongly
demonstrate that pruning anchors and retraining can reduce the resource costs
of an object detector significantly and that our method generalizes to
different anchor-based single shot detectors.

##  1 Related Work

###  1.1 Model scaling

Many real-world object detection applications run on systems where model size
and inference speed are highly constrained. The object detection networks used
in such systems are not selected based on absolute state-of-the-art accuracy
but on the best possible performance given these constraints. To this end,
many model scaling techniques are applied to scale a model towards a certain
size or speed, where the size is determined by the number of parameters in the
network and the speed by the number of floating point operations. In object
detection, it is common to downscale the model by changing the backbone
network (e.g. from VGG (Simonyan and Zisserman (2014)) to MobileNet (Sandler
et al. (2018))), by reducing the input resolution (e.g. from $512\times 512$
to $300\times 300$ in SSD (Liu et al. (2016))), by reducing the number of
layers (e.g. from 50 to 18 in ResNet (He et al. (2016))) or a combination of
these (Tan et al. (2020)). To further trim the computational cost in those
models, techniques such as pruning (Liu et al. (2018)) and quantization (Zhou
et al. (2017)) are often used, possibly in combination with knowledge
distillation (Hinton et al. (2015)) to recover any lost accuracy. Earlier
pruning techniques focused on removing individual weights or connections, but
in recent years, the trend has shifted towards more structural pruning at the
level of filters or even entire layers. Compared to pruning many individual
weights, structural pruning does not need specialized hardware or libraries to
benefit from the sparsity.

However, none of the above scaling techniques are specific to object
detection. We will show in Section 2 that our proposed method of pruning
anchors is an effective way to downscale the computational complexity of the
object detection head. It is orthogonal to the previously mentioned scaling
methods, meaning that they can be combined to achieve better compression
results.

###  1.2 Anchor-based

Anchor-based one-stage detectors are convolutional object detection models
that consist in most cases of three parts. The backbone network is an off-the-
shelf convolutional network, trained originally for image classification, that
extracts features for detecting objects. On top of this backbone, most object
detection models have a middle part, the neck, that adds more layers after the
backbone to produce better adapted features. In SSD (Liu et al. (2016)) the
neck consists of additional convolutional feature layers, while in more recent
networks such as RetinaNet (Lin et al. (2017b)) and EfficientDet (Tan et al.
(2020)) some form of Feature Pyramid Network (FPN) (Lin et al. (2017a)) is
used, that has additional lateral connections with the backbone. The final
part is the object detection head which includes a classifier and regressor to
predict classes and exact locations of the objects in the image. The detection
head is applied to several feature layers which can come from both the
backbone and the neck.

Anchor-based detectors associate some predefined anchors, sometimes also named
default bounding boxes or priors, to each feature layer to which the detection
head is attached. These anchor-associated feature layers are what we will from
now on refer to as feature maps. Usually, the anchors are defined in terms of
size and aspect ratio. The classifier and regressor in the detection head
output the class scores and the 4 offsets relative to the predefined anchor
shape for each pixel in a feature map. While many papers claim that an
increase in the number of anchors leads to an increase in accuracy (Li et al.
(2019); Liu et al. (2016)), we will show in Section 3 that this does not
always hold and that too many anchors can lead to a decrease in accuracy.

###  1.3 Anchor-free

Some one-stage detectors use a different approach. The first version of YOLO
predicted the coordinates of bounding boxes directly using fully connected
layers (Redmon et al. (2016)), the latest versions have however also switched
to using anchors. More recently proposed anchor-free detectors have
deliberately moved away from using anchors. CornerNet (Law and Deng (2018))
for example, detects corners of an object and groups multiple predictions
together to produce a final bounding box. One of the reasons of existence for
FCOS (Tian et al. (2019)), another anchor-free object detector, is that anchor
shapes need to be carefully tuned. While anchor-free methods are growing in
popularity and show promising results, their alternatives to anchors often
mean that the detections made in the object detection head are fixed and
cannot be downscaled to trade accuracy for performance. We believe that
anchor-based solutions are still relevant as they are widely used and as
demonstrated in EfficientDet (Tan et al. (2020)), are able to achieve state-
of-the art results in both accuracy and efficiency.

###  1.4 Anchor shape optimization

One of the reasons to use an anchor-free approach is that the number of
anchors and their predefined shapes can be seen as hyperparameters that need
to be carefully tuned. As stated earlier, anchors are usually defined in terms
of size (or scale) and aspect ratio. The optimal aspect ratios depend strongly
on the domain in which the object detector is applied. For face recognition
square aspect ratios will be important (Zhang et al. (2017)) while for text
detection such as in license plate recognition wider aspect ratios like $1:5$
need to be included (Liao et al. (2018)).

The optimal scales for the anchors in each layer, not only depend on the
domain (i.e. the distribution of the size of the objects) but also on the
receptive field and the stride of the associated feature map. The theoretical
receptive field indicates which pixels in the input image affect the value of
a pixel in the feature map. However as shown in (Luo et al. (2016)), the
effective input region that has a non-negligible impact on this feature map
value is only a fraction of the theoretical receptive field. The stride of the
feature map determines the interval at which anchors are placed. For example,
in SSD the stride size of the first anchor-associated feature map is 8 pixels,
indicating that the anchors produces a bounding box every 8 pixels on the
input image.

To reduce the importance of the initial anchor shapes, RefineDet (Zhang et al.
(2018)) proposes a one-stage object detector with an additional module to
refine anchor locations, alleviating the negative effects of suboptimal anchor
shapes. Other approaches such as Guided Anchoring (Wang et al. (2019)) and
MetaAnchor (Yang et al. (2018)) remove the need for hand-picked anchors all
together by including additional components that generate the anchors.
However, this requires extra resources and results in a larger model and
longer inference time. More recent approaches dynamically learn the anchors
during training, which increases training time but has no influence on the
model size and inference time. FreeAnchor (Zhang et al. (2019)) and MAL (Ke et
al. (2020)) start from a bag of candidate anchors and learn which ones are
optimal, Anchor Box Optimization (Zhong et al. (2020)) adapts the loss and
changes the anchor shapes during back-propagation. These approaches optimize
the anchor shape initialization but still leave the number of anchors as a
hyperparameter. While these approaches benefit from anchor selection during
training, this also means that any modification to the numbers of anchors
requires retraining the network, making it infeasible to use such methods to
efficiently explore accuracy/performance trade-offs. In comparison our
proposed pruning method can obtain an accuracy without any need for re-
training or fine-tuning. Only when a pruned configuration is selected does our
method require fine-tuning or retraining.

Our anchor pruning approach is compatible with these previous anchor shape
optimization methods as it does not change the shapes of the initial anchors
but rather removes the redundant or least important anchors. Models that have
optimized anchor shapes can be used as a baseline from which to start anchor
pruning.

##  2 Anchor Pruning

In this section, we propose an efficient way to explore different anchor
configurations through pruning. We first demonstrate why pruning anchors is a
sensible strategy. Next, we present a search algorithm to determine which
anchors to remove for different resource constraints. The result is a sequence
of anchor configurations that form a Pareto front in the accuracy/performance
design space. This allows model designers to trade-off between accuracy and
performance when selecting their final model.

###  2.1 Redundant Anchors

In a one-stage anchor-based object detector, the total number of predicted
bounding boxes per image is $N=\sum_{i=1}^{k}N_{i}=\sum_{i=1}^{k}(A_{i}\times
H_{i}\times W_{i})$, where $H_{i}$ and $W_{i}$ are the size of the feature
maps, and $A_{i}$ is the number of anchors, for $k$ different feature map
layers. In some object detection architectures $N$ also depends on the number
of classes $C$ but since most recent models separate class-agnostic bounding
box regression from the object classification, we do not include it here. Our
proposed technique can be trivially extended to handle class-specific anchors.

When $\forall i,j\in 1,...,k:A_{i}=A_{j}$ and $H_{i+1}=H_{i}/2$,
$W_{i+1}=W_{i}/2$, as is common in single stage detectors where the feature
maps are often in a pyramid structure, then $N_{1}\approx\frac{3N}{4}$. This
means that the majority of the predicted bounding boxes come from the anchors
associated with the first feature map.

Table 1 shows the relation between the number of anchors per feature map layer
and the total number of bounding boxes as well as the accuracy on the COCO
dataset for different SSD300 models. The first row shows the results when
using the 6 anchors per layer as defined in the scales and aspect ratios
section of the original SSD paper (Liu et al. (2016)). The second row shows
the results for the final SSD300 version reported in the experimental results
section of the original paper where the number of anchors is reduced from 6 to
4 in the first and last two layers. While the original paper does not motivate
why some layers have only 4 instead of 6 anchors, it can be seen from the
results in the table that the choice likely comes from the observation that 6
anchors in the first layer offer less accuracy at a higher computational cost.
The last row in Table 1 shows that further reducing the number of anchors in
that first layer could have improved accuracy and efficiency even more. As we
argued earlier, the optimal number of anchors is a hyperparameter that
requires careful tuning. This example also indicates that more anchors do not
always mean better accuracy, as will be further shown in section 3.

Table 1: Relation between the number of anchors per layer $A_{i}$ and the
total number of bounding boxes $N$ in SSD300. The number of anchors $A_{1}$ in
the first feature map layer have the largest influence on $N$. It can be seen
that reducing this number has a positive influence on both the mean average
precision (mAP) and the number of bounding boxes.
* Marks the original configuration of SSD300 (Liu et al. (2016)). $\\{A_{1},A_{2},A_{3},A_{4},A_{5},A_{6}\\}$ | $N$ | COCO mAP
---|---|---
$\\{6,6,6,6,6,6\\}$ | 11640 | 25.6
$\\{4,6,6,6,4,4\\}$* | 8732 | 25.7
$\\{2,6,6,6,4,4\\}$ | 5844 | 25.8

Analysis of the bounding boxes predicted by each anchor, shows that different
anchors can predict similar bounding box shapes. For example, an object with a
ground truth bounding box of aspect ratio $1:1.5$ could be predicted by a
$1:1$ anchor and a $1:2$ anchor. Figure 1, shows the distribution of the
predicted bounding boxes for each anchor in the first two layers of SSD300 on
the MS COCO dataset. It can be observed that certain anchors produce bounding
boxes that are almost completely covered by predictions of neighboring
anchors, which intuitively explains why it is possible to drop certain anchors
without loss of performance.

Fig. 1: The distribution of the shape of bounding boxes for each anchor in the
first two layers of SSD300 on MS COCO. The markers correspond to the default
shape of each anchor, and the matching colored region to the final bounding
boxes produced by that anchor. Plotted on the side are the marginal
distributions of the width and height.

###  2.2 Optimal Anchor Search

Unlike methods such as magnitude-based pruning of convolutional filters (Li et
al. (2016)), we not only have to decide how much to prune but also what to
prune. Anchors that produce bounding boxes that are largely covered by
neighboring anchors are more optimal to prune than those producing unique
shapes. The number of possible anchor subsets that result from pruning a model
is equal to $|\mathcal{P}(\mathcal{A})|=2^{|\mathcal{A}|}$ where $\mathcal{A}$
is the set of all anchors in the unpruned model and $\mathcal{P}(\mathcal{A})$
stands for the power set of $\mathcal{A}$. Models such as SSD and RetinaNet
have 30 and 45 anchors respectively, which makes it infeasible to evaluate all
combinations. We therefore introduce a greedy search algorithm to efficiently
explore the search space. This procedure is summarized in Algorithm 1.

Algorithm 1 Anchor Pruning Search

Input: Fully trained model $M$ with anchors $\mathcal{A}$
Output: Pareto Frontier $P$

1:Set $S\leftarrow\\{\mathcal{A}\\}$ and $P\leftarrow\\{\mathcal{A}\\}$

2:while $S\neq\emptyset$ do

3: Select a configuration $\mathcal{C}$ from $S$ to explore

4: for each anchor $a_{i}\in\mathcal{C}$ do

5: $\mathcal{C}_{i}=\mathcal{C}\setminus a_{i}$

6: $\texttt{accuracy}_{\mathcal{C}_{i}}$ = Accuracy of $M$, keeping only
predictions produced by anchors in $\mathcal{C}_{i}$

7: $\texttt{cost}_{\mathcal{C}_{i}}$ = Resource cost of $M$ with anchors in
$\mathcal{C}_{i}$

8: Compare $\texttt{accuracy}_{\mathcal{C}_{i}}$ and
$\texttt{cost}_{\mathcal{C}_{i}}$ to
$\texttt{accuracy}_{\mathcal{C}_{j}}$ and $\texttt{cost}_{\mathcal{C}_{j}}$
from all $\mathcal{C}_{j}\in P$

9: if $\mathcal{C}_{i}$ is Pareto Optimal in $P$ then

10: Add $\mathcal{C}_{i}$ to $P$ and $S$

11: end if

12: Remove any $\mathcal{C}_{i}$ that is no longer optimal from $P$

13: end for

14:end while

Our anchor pruning algorithm starts from a fully (pre-)trained model $M$ with
anchor configuration $\mathcal{C}=\mathcal{A}$. The algorithm iterates over an
adapting set of unexplored anchor configurations $S$ and constructs a set of
Pareto-efficient anchor configurations $P$. Starting from
$S=\\{\mathcal{A}\\}$ and $P=\\{\mathcal{A}\\}$, we take an unexplored
configuration $\mathcal{C}$ ($\mathcal{C}\subseteq\mathcal{A}$) from $S$ at
each iteration until $S=\emptyset$. From anchor configuration $\mathcal{C}$ we
evaluate configurations $\mathcal{C}_{1},...,\mathcal{C}_{n}$, where
$\mathcal{C}_{i}=\mathcal{C}\setminus a_{i}$, with anchor
$a_{i}\in\mathcal{C}$.

Evaluating a configuration $\mathcal{C}$ means evaluating the accuracy of the
model $M$ when only using the predictions made by anchors
$a_{i}\in\mathcal{C}$. This can be done in an efficient way by initially
storing all predicted bounding boxes from $M$, i.e. before any are discarded
by post-processing steps such as NMS, and to re-evaluate by only keeping the
bounding boxes produced by anchors $a_{i}$ in the configuration $\mathcal{C}$.
This avoids the costly process of running all validation inputs through an
adapted model for each new configuration. The evaluation of the accuracy
metric should be done on a validation set to avoid overfitting the anchor
configurations on the test set. As stated before, we are not just interested
in the highest accuracy but in the accuracy/resources trade-off. This requires
evaluating an accuracy metric (e.g. mean average precision (mAP), F-score,
etc.) and a resource metric (e.g. inference speed, FLOPs, model size, number
of predicted bounding boxes, etc.). Resource metrics that can be calculated
such as FLOPs should be preferred above metrics that need to be experimentally
measured such as inference speed.

A configuration is Pareto-optimal or Pareto-efficient when no other node that
uses fewer or equal resources achieves higher accuracy. At any point during
the search phase, $P$ stores the Pareto-optimal configurations that have been
evaluated thus far. To achieve this, the accuracy and resource cost of
$\mathcal{C}_{i}$ are compared to all $\mathcal{C}_{j}\in P$, if
$\mathcal{C}_{i}$ is Pareto optimal in $P$ we add $\mathcal{C}_{i}$ to $P$ and
$S$, and any $\mathcal{C}_{j}$ that is no longer Pareto optimal is removed
from $P$. To speedup the running time of the search algorithm, one could also
add an accuracy threshold $\theta$ such that $\mathcal{C}_{i}$ is only added
to $P$ and $S$ if it is Pareto Optimal in $P$ and
$\texttt{accuracy}_{\mathcal{C}_{i}}\geq\theta$. This is often useful in
practice when we are only interested in accuracy/resources trade-offs as long
as the accuracy remains acceptable. Once $S$ is empty, $P$ contains all
Pareto-efficient anchor configurations.

Because the search is greedy, $P$ might contain configurations that are
suboptimal solutions as the algorithm may miss anchor combinations that would
arise from further pruning discarded configurations. However, as we will show
in Section 3, our method significantly outperforms random pruning and the
default pruning approach from RetinaNet.

##  3 Experiments

###  3.1 Setup

Our proposed anchor pruning is rather general and can be applied to any
anchor-based one-stage object detector. We demonstrate our results primarily
on SSD300 (Liu et al. (2016)), one of the most used and influential one-stage
object detectors. SSD uses a VGG16 backbone, a pyramid of convolutional
feature maps in the neck, and a head with a $3\times
3\times(A_{i}\times(Classes+4))$ convolution on top of each of the 6 feature
maps. Each feature map has anchors of a fixed scale and with aspect ratios of
$\\{1,2,\frac{1}{2},3,\frac{1}{3}\\}$ and an additional anchor with aspect
ratio $1$ but a larger scale (which we will refer to as $1^{+}$), resulting in
6 anchors per layer. However for the first and the two last feature maps, the
anchors with aspect ratios $3$ and $\frac{1}{3}$ are removed, resulting in a
total of $30$ anchors.

While SSD is no longer a state-of-the-art object detection model, as many
alternatives that are both more accurate and more efficient have been
developed since its publication, the fundamental structure of the Single-Shot-
Detector remains used in most recent object detectors.

Table 2 shows the FLOPs (multiply-adds) of different object detection models
along with how many of those FLOPs are in the detection head. It can be seen
that the relative importance of the head has increased as backbones got more
efficient in more recent object detectors. Given the growing focus on
resource-efficient models, we expect this trend to continue. We will show in
Section 3.6 that our method generalizes well to these more recent anchor-based
one-staged object detectors.

As stated in the introduction, the running time of an object detection model
in an embedded context is often dominated by the running time of the post
processing steps, which is directly related to the number of bounding boxes
produced by the network. In systems where this post-processing bottleneck is
not present, the running time will be directly related to the FLOPs of the
model, and as our approach is backbone independent we only report on those
FLOPs in the head. In the remainder of this work we report the resource cost
as FLOPs in the head of the network or as the number of bounding boxes it
produces. Compared to reporting latency which is very implementation and
hardware dependent, we believe that our reported metrics allow model designers
to better estimate the accuracy/resource trade-offs that are possible for
their platform.

Table 2: The number of FLOPs for different one-stage object detectors, along with the percentage of the FLOPs that take place in the head of the network. FLOPs are calculated for an input resolution of $300\times 300$. Model | FLOPs | FLOPs(%) head
---|---|---
SSD | 34.4B | 12.3%
RetinaNet | 21.7B | 57.6%
MobileNetV3-Small-SSDLite | 0.2B | 37.5%
Table 3: Results on COCO test-dev2017 from the evaluation server for different anchor configurations of SSD. The models are ordered in decreasing number of bounding boxes and FLOPs. AP.5:.95 is the COCO mAP, AR the average precision and subscripts S/M/L correspond to small, medium and large objects. The superscripts 2,3,4,5 refer to the subsection of Section 3 where the details of the relevant experiments can be found. Model (SSD variant) | AP.5:.95 | AP50 | AP75 | APS | APM | APL | ARS | ARM | ARL |  | FLOPs
---
head
BBoxes
SSD Baseline | 25.7 | 44.0 | 26.6 | 7.1 | 27.1 | 41.6 | 11.2 | 39.9 | 57.6 | 4231M | 8732
SSD $\\{1,2,\frac{1}{2},1^{+}\\}^{4}$ | 25.5 | 43.7 | 26.2 | 7.3 | 26.6 | 40.8 | 11.6 | 39.6 | 56.5 | 3577M | 7760
SSD $\\{1,1^{+}\\}^{4,5}$ | 25.0 | 43.3 | 25.5 | 7.2 | 25.6 | 39.6 | 12.7 | 39.0 | 56.1 | 1788M | 3880
Configuration-A pruned2,3 | 25.6 | 43.9 | 26.5 | 7.1 | 27.1 | 41.2 | 11.2 | 39.8 | 57.2 | 3607M | 7814
Configuration-A fine-tuned3 | 25.7 | 44.0 | 26.6 | 7.2 | 27.2 | 41.3 | 11.3 | 39.7 | 57.3 | 3607M | 7814
Configuration-A retrained3 | 25.5 | 44.0 | 26.3 | 7.6 | 27.2 | 40.4 | 11.8 | 39.8 | 56.4 | 3607M | 7814
Configuration-B retrained3,4 | 25.8 | 44.5 | 26.5 | 6.8 | 27.2 | 41.2 | 12.0 | 40.1 | 57.3 | 2476M | 4926
Configuration-C retrained3,4,5 | 25.4 | 44.3 | 25.7 | 6.5 | 25.7 | 41.6 | 12.5 | 38.2 | 58.0 | 1628M | 3121
Configuration-D retrained3 | 23.1 | 41.5 | 23.1 | 3.7 | 22.6 | 41.4 | 7.3 | 35.4 | 58.0 | 774M | 1291
Pruned Layer-wise4 | 25.0 | 43.6 | 25.5 | 7.5 | 26.5 | 38.1 | 13.0 | 39.3 | 54.8 | 1788M | 3880
Overanchorized5 | 25.8 | 43.5 | 27.0 | 6.6 | 28.4 | 42.1 | 9.7 | 40.7 | 59.1 | 6673M | 13584
Pruned Overanchorized5 | 25.3 | 44.0 | 25.7 | 6.5 | 25.6 | 42.1 | 12.3 | 37.4 | 58.8 | 1620M | 3080

We evaluate pruning anchors of the SSD model on the MS COCO 2017 detection
dataset Lin et al. (2014). Before pruning, the SSD model is trained on
train2017 using SGD for 120 epochs with a learning rate of $10^{-3}$, which is
decreased to $10^{-4}$ on epoch 80 and to $10^{-5}$ on epoch 110, with a
weight decay of $5\times 10^{-4}$ and a momentum of $0.9$. The input images
are resized to $300\times 300$ and all data augmentations as described in (Liu
et al. (2016)) are used. The accuracy metric used for COCO is the mean average
precision (mAP) evaluated at intersection-over-union (IoU) thresholds evenly
distributed between 0.5 and 0.95, for the resource metric we use the number of
FLOPs in the object detection head. Our anchor pruning search, uses val2017 to
evaluate candidate anchor configurations.

###  3.2 Pruning

Figure 2 shows the Pareto frontier of pruned anchor configurations as obtained
by our search algorithm, representing points at which fewer FLOPs can only be
achieved by sacrificing accuracy. We also highlight the original unpruned
model and plot the results of configurations achieved when pruning anchors
randomly. As can be seen in the figure, our method outperforms random pruning
for all FLOPs, indicating our effectiveness in pruning anchors that are
redundant or that lead to minimal accuracy loss. For pruned models that have a
large reduction in FLOPs and therefore require more anchors to be pruned,
selecting the right anchors can be the difference between a model with
acceptable accuracy and a model that is no longer usable because the accuracy
dropped too much. Note that the wider gaps on the x-axis between anchor
configurations in the Pareto frontier are due to pruned anchors that have a
large influence on the number of FLOPs, such as anchors in the first layer of
the head.

The most accurate configuration produced by our search algorithm, which we
will refer to as Configuration-A pruned, is able to reduce the number of FLOPs
in the detection head by 15% without losing any accuracy on the val2017
dataset. Table 3 shows the accuracy in more detail on the test-dev2017
dataset, indicating that the accuracy degraded slightly for large objects.
This is not surprising as Configuration-A pruned 5 of the 8 largest anchors.

Fig. 2: Accuracy and FLOPs trade-offs for different optimal anchor
configurations found by our anchor pruning search. The Pareto frontier is
highlighted in orange, the unpruned baseline in blue. Accuracy is measured on
the COCO val2017 dataset and FLOPs indicate the multiply-adds in the detection
head.

###  3.3 Fine-tuning versus Retraining

Fig. 3: Accuracy of fine-tuning and retraining certain highlighted
configurations for SSD on COCO val2017. Fine-tuning improves accuracy after
pruning but in most cases, retraining achieves a much higher accuracy.

Most pruning techniques fine-tune the model after pruning to recover part of
the lost accuracy. In this section, we show the impact of fine-tuning after
pruning anchors and compare it to retraining the model from scratch with the
new anchor configuration. When fine-tuning we train for 10 additional epochs
with a learning rate of $10^{-5}$, for retraining we use the same settings as
described in Section 3.1. Figure 3 shows the effect of fine-tuning and
retraining on four highlighted configurations. As illustrated in the figure,
fine-tuning does recover some of the lost performance during pruning. However,
for all nodes except Configuration-A, retraining the configuration from
scratch achieves much higher accuracy. As more anchors get pruned, such as in
Configuration-D, the difference between fine-tuning and retraining increases.
The Pareto frontier produced by Algorithm 1 can be seen as a lower bound for
the accuracy that can be achieved for those configurations after fine-tuning
or retraining.

On the val2017 dataset there are now multiple configurations that match the
unpruned baseline accuracy: Configuration-A pruned, Configuration-A fine-tuned
and Configuration-B retrained. Further evaluation on the test-dev2017 dataset,
as shown in Table 3, indicates that Configuration-A fine-tuned is able to
restore the lost performance as reported in the previous section and
Configuration-B retrained is able to reduce the FLOPs and the number of
bounding boxes by around 43% while even slightly improving accuracy.

###  3.4 Layer-wise Pruning

Experimenting with anchor configuration in the head of an object detector is
not new, but it is normally done before training and in a symmetric way.
Adding or removing anchor shapes is done across all layers and when the aspect
ratio $x$ is added/removed, $\frac{1}{x}$ is also added/removed. The original
SSD paper does mention two additional anchor settings compared to the
baseline; one where aspect ratios $1$ and $\frac{1}{3}$ are removed, and one
which is further reduced by removing aspect ratios $2,\frac{1}{2}$. Just like
our retraining approach, these additional models are trained from scratched
rather than created by pruning the larger baseline. We compare these ‘default’
settings to configurations in our Pareto frontier that have a comparable
number of FLOPs. The SSD setting where aspect ratios $3$, $\frac{1}{3}$ are
removed has a performance drop of 0.2% on COCO. In the previous subsection, we
already showed that we can prune much more than that while simultaneously
improving accuracy. The SSD setting with only two square anchors per layer has
a performance drop of 0.7%. Configuration-C retrained has a comparable number
of FLOPs to this setting but only results in 0.3% reduced accuracy. We also
compare to a pruned model where the anchors are pruned layer by layer until 2
anchors per layer remain. While the layer-wise pruning configuration keeps
other aspect ratios besides $1:1$, it does result in comparable accuracy
(after retraining) to the last mentioned SSD setting, indicating the
importance of pruning freely over all layers as we do in Algorithm 1. The
detailed results can be found in Table 3.

###  3.5 Overanchorized Model

As explained in Section 1, predefined anchors introduce many additional
hyperparameters that require careful tuning. We introduce an ‘overanchorized’
model and define it as an object detection model that has more anchors than
strictly needed. For applications where computational resources are not
constrained, our previous experiments showed that while more anchors do not
always improve accuracy, they also do not degrade the accuracy significantly.
For applications with constrained-resources we can prune from an
overanchorized model to arrive at an optimized anchor configuration. This also
allows our algorithm to find a suitable set of anchors if no initial anchors
with good performance are known. As an experiment, we defined an
overanchorized SSD model with 48 anchors (see Figure 4) and pruned it to a
model where the number FLOPs is below or equal to the SSD setting with two
anchors per layer. Figure 4 plots the anchors selected by the pruning step.
The detailed results in Table 3 show that pruning an overanchorized model
achieves comparable accuracy to pruning the original baseline. This suggests
that training an overanchorized object detection model followed by anchor
pruning can eliminate extensive tuning of the anchor shapes, while
simultaneously removing the number of anchors as a hyperparameter.

Fig. 4: Anchor shapes for the ‘overanchorized’ SSD model and the anchors that
remain after pruning. The overanchorized model has 48 anchors that produce
13584 bounding boxes and achieves 25.8 mAP on COCO. The pruned version only
has 14 anchors producing 3080 bounding boxes and achieves 25.4 mAP.

###  3.6 RetinaNet

As stated earlier, our approach is general as it can be applied to different
one-stage anchor-based object detectors. In this subsection we demonstrate
that our technique is also successful on more recent object detectors such as
RetinaNet. The default configuration of RetinaNet uses 9 anchors in each layer
by combining 3 scales and 3 aspect ratios $\\{\frac{1}{2},1,2\\}$. As shown
earlier in Table 2, unlike most object detectors, the majority of FLOPs in
this model take place in the head. The explanation for this is that whereas
the head in SSD directly does a $3\times 3\times(A_{i}\times(Classes+4))$
convolution, RetinaNet first applies 4 additional $3\times 3\times 256$
convolutional layers. Another difference with SSD is that these prediction
layers in the detection head are reused on all feature maps. To account for
these differences, we apply the following changes to Algorithm 1:
Configuration $\mathcal{C}$ generates $\mathcal{C}_{i}$ by either removing a
certain anchor configuration on each layer or by removing all anchors of a
certain layer (as the prediction layers are shared, this practically means not
applying the head on a certain feature map).

Fig. 5: Accuracy and number of FLOPs for pruned anchor configurations of
RetinaNet on COCO val2017. The Pareto frontiers are optimized for the number
of FLOPs or the number of bounding boxes.

An important side effect of the additional convolutional layers in the
RetinaNet head, is that the decision not to apply the head to a certain
feature map has a large influence on the number of FLOPs but not necessarily
on the number of bounding boxes. Because of this property, we use RetinaNet to
show the difference between optimizing for the number of FLOPs or optimizing
the number of bounding boxes. When optimizing an object detector for a certain
use-case, the used hardware will determine whether the computations in the
convolutional layers or the post-processing steps on the bounding boxes are
the most time consuming. The resulting Pareto frontiers can be found in Figure
5. The large jump in FLOPs in both frontiers happens when the head is no
longer applied to the first feature map. The difference is that in the FLOPs
frontier the remaining layers still have 8 anchors left, while in the bounding
boxes frontier there are only 5 anchors left.

Table 4: Accuracy, FLOPs and inference time for RetinaNet variants on COCO test-dev2017. Our pruned model can reduce the FLOPs by 75% compared to the baseline (s3a3) while being much more accurate than the smallest original RetinaNet head (s1a1). Inference times are measured on an Nvidia GTX 1080. Model | AP.5:.95 |  | FLOPs
---
head
| FLOPs
---
total
inf time
RetinaNet(s3a3) | 36.9 | 129B | 224B | 137 ms
RetinaNet(s1a1) | 31.0 | 98B | 193B | 99 ms
Pruned | 33.9 | 31B | 126B | 79 ms
Pruned(+retrained) | 35.1 | 31B | 126B | 79 ms

Table 4 compares the result of retraining this FLOPs frontier configuration to
the baseline and a RetinaNet version with only 1 anchor in each layer as
reported in the original paper. Not only does our pruned configuration achieve
4.1% better accuracy, it can also reduce the computational cost of the head by
75% compared to the RetinaNet (s3a3) baseline and by 68% compared to RetinaNet
(s1a1). This means that our method is able to reduce the FLOPs of the entire
RetinaNet model by 44% while only losing 1.8% accuracy which is $3\times$
better compression and 4.1% better accuracy than the default way of scaling
anchors, i.e. RetinaNet(s1a1), which only reduces the FLOPs by 14% while also
decreasing the accuracy by 5.9%.

These results also illustrate the importance of adapting the anchor pruning
search to the object detection architecture; without allowing an entire layer
to be dropped it is impossible to significantly decrease the number of FLOPs.

The training configurations used for RetinaNet are based on the MMDetection
Chen et al. (2019) RetinaNet baseline configuration with ResNet50 backbone and
$1\times$ learning rate schedule. All models are trained using SGD for 12
epochs with an initial learning rate of $0.01$ which is decreased to $10^{-3}$
on epoch 8 and $10^{-4}$ on epoch 11, the weight decay is $10^{-4}$ and the
momentum $0.9$. The input images are resized to 800 pixels on the shortest
side, and random horizontal flipping is used as data augmentation.

###  3.7 MobileNetV2-SSDLite

To further demonstrate the generalization of our approach we also conducted
experiments on an SSD object detector with a more compact backbone. It is
generally assumed that compact models such as MobileNet (Sandler et al.
(2018)) and ShuffleNet (Hu et al. (2018)) are harder to prune due to their
already compact layers (Zhu and Gupta (2017)). For anchor pruning we show that
the used backbone is not of importance as the pruning happens in the object
detection head. The only important factor in anchor pruning is the placement
of the original anchors. Figure 6 shows the Pareto Frontiers for
MobileNetV2-SSDLite and the original SSD model. Both frontiers follow a
similar trend line, indicating that anchor pruning is backbone agnostic. The
main difference between the two trend lines is the slightly worse accuracy
degradation on the left side in the MobileNet frontier. This is however
explained by the fact that MobileNetV2-SSDLite model has only 3 anchors in the
first layer compared to 4 in the original SSD model.

Fig. 6: Accuracy and number of FLOPs relative to the unpruned models for
MobileNetV2-SSDLite and the original SSD on COCO val2017. Both rontiers have a
similar trend line, indicating that anchor pruning is backbone agnostic.

###  3.8 PASCAL VOC

For completeness and to further demonstrate the generalization of our
approach, we also evaluate our approach on the PASCAL VOC (Everingham et al.
(2010)) dataset. As is common, we use the combined datasets of VOC2007 and
VOC2012. To reproduce the SSD baseline in the same way as the original paper,
we change the anchor scales to the values specific for PASCAL VOC as defined
in (Liu et al. (2016)). The training configuration remains identical to the
one used for COCO, with the exception that it is run for twice as many epochs.

The Pareto frontier for SSD on this dataset can be found in Figure 7. The
reported mAP is with an IoU threshold of 0.50 as is custom for evaluating on
this dataset. It can be seen that anchor pruning with retraining can achieve
similar mAP as the baseline with more than 50% FLOPs reduction.

As SSD uses different anchor shape initialization for PASCAL VOC compared to
COCO, we also included an ‘overanchorized’ model that has the same initial
anchors as in the experiments of Section 3.5. For both PASCAL VOC and COCO
pruning from the same ‘overanchorized’ model results in an improvement over
the baseline models. This demonstrates that anchor pruning can not only
eliminate the number of anchors as parameters but also the shapes of the
anchors when used with an ‘overanchorized’ detection head.

Fig. 7: Accuracy and number of FLOPs for anchor pruning configurations in the
Pareto frontiers for the SSD baseline and ‘overanchorized‘ model on PASCAL
VOC. Note how pruning certain anchors results in improved accuracy compared to
the baseline, even before any fine-tuning or retraining.

Compared to the results on COCO, pruning SSD on PASCAL VOC shows an additional
interesting property; removing certain anchors immediately improves accuracy,
even before fine-tuning or retraining. This can be explained by looking at the
pruned anchors. For example, the most accurate configuration prunes, among
others, all anchors in the last layer. In SSD the last layer of the head
operates on a $1\times 1$ feature map while the previous layer operates on a
$3\times 3$ feature map. When anchors from both these layers make a prediction
about the same large object, the anchor from the layer with the larger feature
map has more spatial information which can lead to more accurate bounding box
predictions. The example image in Figure 8 illustrates this: while the anchor
from the last layer is more confident in its prediction, the anchor from the
previous layer is more accurate in predicting the bounding box shape.
Depending on the network structure in the backbone and neck, removing all
anchors on the last feature map may make this layer obsolete and reduce the
computational complexity of the entire network even further.

Fig. 8: An example illustrating how predictions made by a large anchor can be
more confident but less accurate (a) than predictions made by a smaller anchor
in an earlier layer (b).

##  4 Conclusion

In this paper, we proposed a novel pruning method for one-stage anchor-based
object detection models: anchor pruning. We show that in most object detectors
many anchors are redundant and that pruning those anchors followed by a fine-
tuning or retraining step can increase accuracy while simultaneously reducing
the computational cost. Through a simple yet effective search algorithm, we
provide a Pareto frontier of anchor configurations, allowing model designers
to trade accuracy for performance when resources are constrained. We
demonstrate the effects of pruning anchors extensively on the SSD and
RetinaNet object detectors and the MS COCO and PASCAL VOC datasets. We also
show that through pruning an ‘overanchorized’ model we avoid tuning
hyperparameters related to the initial shapes of the anchors. Given its
effectiveness to make object detection models more efficient, we hope that
anchor pruning will become part of the design process for modern one-stage
object detectors.

## Acknowledgments

This research received funding through the imec.icon project cREAtIve and the
Research Foundation Flanders (FWO-Vlaanderen) under Grant G006718N and
1S47820N.

## References

  * Cai et al. (2019) Cai, L., Zhao, B., Wang, Z., Lin, J., Foo, C.S., Aly, M.S., Chandrasekhar, V., 2019\.  Maxpoolnms: getting rid of nms bottlenecks in two-stage object detectors, in: Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp. 9356–9364.
  * Cai and Vasconcelos (2018) Cai, Z., Vasconcelos, N., 2018\.  Cascade r-cnn: Delving into high quality object detection, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 6154–6162.
  * Chen et al. (2019) Chen, K., Wang, J., Pang, J., Cao, Y., Xiong, Y., Li, X., Sun, S., Feng, W., Liu, Z., Xu, J., Zhang, Z., Cheng, D., Zhu, C., Cheng, T., Zhao, Q., Li, B., Lu, X., Zhu, R., Wu, Y., Dai, J., Wang, J., Shi, J., Ouyang, W., Loy, C.C., Lin, D., 2019.  MMDetection: Open mmlab detection toolbox and benchmark.  arXiv preprint arXiv:1906.07155 .
  * Deng et al. (2020) Deng, L., Li, G., Han, S., Shi, L., Xie, Y., 2020\.  Model compression and hardware acceleration for neural networks: A comprehensive survey.  Proceedings of the IEEE 108, 485–532.
  * Everingham et al. (2010) Everingham, M., Van Gool, L., Williams, C.K., Winn, J., Zisserman, A., 2010.  The pascal visual object classes (voc) challenge.  International journal of computer vision 88, 303–338.
  * Girshick (2015) Girshick, R., 2015.  Fast r-cnn, in: Proceedings of the IEEE international conference on computer vision, pp. 1440–1448.
  * He et al. (2016) He, K., Zhang, X., Ren, S., Sun, J., 2016.  Deep residual learning for image recognition, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 770–778.
  * Hinton et al. (2015) Hinton, G., Vinyals, O., Dean, J., 2015.  Distilling the knowledge in a neural network.  arXiv preprint arXiv:1503.02531 .
  * Hu et al. (2018) Hu, J., Shen, L., Sun, G., 2018.  Squeeze-and-excitation networks, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 7132–7141.
  * Huang et al. (2017) Huang, J., Rathod, V., Sun, C., Zhu, M., Korattikara, A., Fathi, A., Fischer, I., Wojna, Z., Song, Y., Guadarrama, S., et al., 2017\.  Speed/accuracy trade-offs for modern convolutional object detectors, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 7310–7311.
  * Ke et al. (2020) Ke, W., Zhang, T., Huang, Z., Ye, Q., Liu, J., Huang, D., 2020.  Multiple anchor learning for visual object detection, in: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pp. 10206–10215.
  * Law and Deng (2018) Law, H., Deng, J., 2018.  Cornernet: Detecting objects as paired keypoints, in: Proceedings of the European Conference on Computer Vision (ECCV), pp. 734–750.
  * Li et al. (2016) Li, H., Kadav, A., Durdanovic, I., Samet, H., Graf, H.P., 2016.  Pruning filters for efficient convnets.  arXiv preprint arXiv:1608.08710 .
  * Li et al. (2019) Li, S., Yang, L., Huang, J., Hua, X.S., Zhang, L., 2019\.  Dynamic anchor feature selection for single-shot object detection, in: Proceedings of the IEEE International Conference on Computer Vision, pp. 6609–6618.
  * Liao et al. (2018) Liao, M., Shi, B., Bai, X., 2018.  Textboxes++: A single-shot oriented scene text detector.  IEEE transactions on image processing 27, 3676–3690.
  * Lin et al. (2017a) Lin, T.Y., Dollár, P., Girshick, R., He, K., Hariharan, B., Belongie, S., 2017a.  Feature pyramid networks for object detection, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 2117–2125.
  * Lin et al. (2017b) Lin, T.Y., Goyal, P., Girshick, R., He, K., Dollár, P., 2017b.  Focal loss for dense object detection, in: Proceedings of the IEEE international conference on computer vision, pp. 2980–2988.
  * Lin et al. (2014) Lin, T.Y., Maire, M., Belongie, S., Hays, J., Perona, P., Ramanan, D., Dollár, P., Zitnick, C.L., 2014\.  Microsoft coco: Common objects in context, in: European conference on computer vision, Springer. pp. 740–755.
  * Liu et al. (2016) Liu, W., Anguelov, D., Erhan, D., Szegedy, C., Reed, S., Fu, C.Y., Berg, A.C., 2016.  Ssd: Single shot multibox detector, in: European conference on computer vision, Springer. pp. 21–37.
  * Liu et al. (2018) Liu, Z., Sun, M., Zhou, T., Huang, G., Darrell, T., 2018\.  Rethinking the value of network pruning.  arXiv preprint arXiv:1810.05270 .
  * Luo et al. (2016) Luo, W., Li, Y., Urtasun, R., Zemel, R., 2016.  Understanding the effective receptive field in deep convolutional neural networks, in: Advances in neural information processing systems, pp. 4898–4906.
  * Redmon et al. (2016) Redmon, J., Divvala, S., Girshick, R., Farhadi, A., 2016\.  You only look once: Unified, real-time object detection, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 779–788.
  * Redmon and Farhadi (2017) Redmon, J., Farhadi, A., 2017\.  Yolo9000: better, faster, stronger, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 7263–7271.
  * Redmon and Farhadi (2018) Redmon, J., Farhadi, A., 2018\.  Yolov3: An incremental improvement.  arXiv preprint arXiv:1804.02767 .
  * Ren et al. (2015) Ren, S., He, K., Girshick, R., Sun, J., 2015.  Faster r-cnn: Towards real-time object detection with region proposal networks, in: Advances in neural information processing systems, pp. 91–99.
  * Sandler et al. (2018) Sandler, M., Howard, A., Zhu, M., Zhmoginov, A., Chen, L.C., 2018.  Mobilenetv2: Inverted residuals and linear bottlenecks, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 4510–4520.
  * Sermanet et al. (2013) Sermanet, P., Eigen, D., Zhang, X., Mathieu, M., Fergus, R., LeCun, Y., 2013\.  Overfeat: Integrated recognition, localization and detection using convolutional networks.  arXiv preprint arXiv:1312.6229 .
  * Simonyan and Zisserman (2014) Simonyan, K., Zisserman, A., 2014\.  Very deep convolutional networks for large-scale image recognition.  arXiv preprint arXiv:1409.1556 .
  * Tan et al. (2020) Tan, M., Pang, R., Le, Q.V., 2020.  Efficientdet: Scalable and efficient object detection, in: Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pp. 10781–10790.
  * Tian et al. (2019) Tian, Z., Shen, C., Chen, H., He, T., 2019.  Fcos: Fully convolutional one-stage object detection, in: Proceedings of the IEEE international conference on computer vision, pp. 9627–9636.
  * Verucchi et al. (2020) Verucchi, M., Brilli, G., Sapienza, D., Verasani, M., Arena, M., Gatti, F., Capotondi, A., Cavicchioli, R., Bertogna, M., Solieri, M., 2020\.  A systematic assessment of embedded neural networks for object detection, in: 2020 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), IEEE. pp. 937–944.
  * Wang et al. (2019) Wang, J., Chen, K., Yang, S., Loy, C.C., Lin, D., 2019\.  Region proposal by guided anchoring, in: Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp. 2965–2974.
  * Yang et al. (2018) Yang, T., Zhang, X., Li, Z., Zhang, W., Sun, J., 2018\.  Metaanchor: Learning to detect objects with customized anchors, in: Advances in Neural Information Processing Systems, pp. 320–330.
  * Zhang et al. (2018) Zhang, S., Wen, L., Bian, X., Lei, Z., Li, S.Z., 2018\.  Single-shot refinement neural network for object detection, in: Proceedings of the IEEE conference on computer vision and pattern recognition, pp. 4203–4212.
  * Zhang et al. (2017) Zhang, S., Zhu, X., Lei, Z., Shi, H., Wang, X., Li, S.Z., 2017.  S3fd: Single shot scale-invariant face detector, in: Proceedings of the IEEE international conference on computer vision, pp. 192–201.
  * Zhang et al. (2019) Zhang, X., Wan, F., Liu, C., Ji, R., Ye, Q., 2019\.  Freeanchor: Learning to match anchors for visual object detection, in: Advances in Neural Information Processing Systems, pp. 147–155.
  * Zhong et al. (2020) Zhong, Y., Wang, J., Peng, J., Zhang, L., 2020.  Anchor box optimization for object detection, in: The IEEE Winter Conference on Applications of Computer Vision, pp. 1286–1294.
  * Zhou et al. (2017) Zhou, A., Yao, A., Guo, Y., Xu, L., Chen, Y., 2017\.  Incremental network quantization: Towards lossless cnns with low-precision weights.  arXiv preprint arXiv:1702.03044 .
  * Zhu and Gupta (2017) Zhu, M., Gupta, S., 2017.  To prune, or not to prune: exploring the efficacy of pruning for model compression.  arXiv preprint arXiv:1710.01878 .


# Does Code Smell Frequency Have a Relationship with Fault-proneness?

Md. Masudur Rahman  Institute of Information Technology, University of
DhakaDhakaBangladesh1000<EMAIL_ADDRESS>,  Toukir Ahammed  Institute of
Information Technology, University of DhakaDhakaBangladesh1000
<EMAIL_ADDRESS>,  Md. Mahbubul Alam Joarder  Institute of Information
Technology, University of DhakaDhakaBangladesh1000<EMAIL_ADDRESS>and
Kazi Sakib  Institute of Information Technology, University of
DhakaDhakaBangladesh1000<EMAIL_ADDRESS>
###### Abstract.

Fault-proneness is an indication of programming errors that decreases software
quality and maintainability. On the contrary, code smell is a symptom of
potential design problems which has impact on fault-proneness. In the
literature, negative impact of code smells on fault-proneness has been
investigated. However, it is still unclear that how frequency of each code
smell type impacts on the fault-proneness. To mitigate this research gap, we
present an empirical study to identify whether frequency of individual code
smell types has a relationship with fault-proneness. More specifically, we
identify 13 code smell types and fault-proneness of the corresponding smelly
classes in the well-known open source systems from Apache and Eclipse
ecosystems. Then we analyse the relationship between their frequency of
occurrences based on the correlation. The results show that Anti Singleton,
Blob and Class Data Should Be Private smell types have strong relationship
with fault-proneness though their frequencies are not very high. On the other
hand, comparatively high frequent code smell types such as Complex Class,
Large Class and Long Parameter List have moderate relationship with fault-
proneness. These findings will assist developers to prioritize code smells
while performing refactoring activities in order to improve software quality.

code smell, fault proneness, empirical study

††ccs: Software and its engineering††ccs: Software systems††ccs: Code smells

##  1\. Introduction

Fault-proneness is an important measure of software maintainability stating
that how likely a piece of code is to contain errors (Gondra, 2008). It is
based on the number of faults that have been found in a software system. On
the other hand, code smells are potential indicators of poor design and
implementation choices by developers while developing and maintaining a
software system (Fowler et al., 1999). These smells are not programming errors
and do not hamper the program’s execution, but make the program complex and
affect comprehensibility and maintainability of the system (Palomba et al.,
2018b; Sjøberg et al., 2012).

However, the presence of code smells indicates the possibility of introducing
faults, and thus increasing maintenance time in the long run (Yamashita and
Moonen, 2012). Therefore, there exists a relationship between code smells and
fault-proneness of a system. Minimizing the occurrences of faults by removing
important or impacted code smells is one of the goals of software developers
in the system’s maintenance phase. Additionally, since it takes a lot of time,
it is very difficult for the developers to eliminate or work with all of the
smell types at a time particularly from a produced system. However, frequency
of all the smell types does not have the same impact on the fault-proneness.
Therefore, it is necessary to identify the relationship between the frequency
of each code smell type and fault-proneness, and identify the impactful set of
smell types. Thus the developers will be enlightened with the impactful code
smell types, and by refactoring these smells on priority basis, the system’s
maintainability will be improved with respect to the fault-proneness.

Previous studies have investigated the relationship between code smells and
fault-proneness, but most of the cases they have not considered individual
type of smell frequency. However, our work is inspired by the previous study
of Palomba et el. (Palomba et al., 2018b), where they investigated the
relationship between the occurrence of code smells in software systems and
software fault-proneness. Particularly, they showed that smelly classes are
highly fault-prone than non-smelly classes. The similar kind of result has
also been found by the study of Khomh et al. (Khomh et al., 2012).
Specifically, while the previous works show a significant relationship between
smells and fault-proneness, impact of individual type of smell frequency on
fault-proneness is still unclear. That is, frequency of which code smell types
are highly correlated with the fault-proneness. To mitigate this research gap,
we present an empirical study aimed at investigating whether there exists
relationship between the frequency of each code smell type and fault-proneness
to identify their individual impact.

In order to conduct the analysis, an empirical study has been carried out on
11 well-known open source Java systems. From these systems, we have identified
13 types of code smells and fault-proneness of each individual smelly classes
to measure the relationship between their frequencies based on the correlation
analysis. The results of this study show the positive relationship between the
smell frequency and fault-proneness. However, three code smell types, namely -
Anti Singleton, Blob and Class Data Should Be Private have higher correlation
with fault-proneness though their frequencies are not very high. On the other
hand, Complex Class, Large Class and Long Parameter List smell types have high
frequency with moderate correlation, and other smell types have both low
correlation and low frequency.

##  2\. Related Work

After defining 22 types of code smells by M. Fowler and K. Beck (Fowler et
al., 1999), many of works have been performed to analyse the impact of code
smells on software maintainability.

Khomh et al. (Khomh et al., 2012, 2009) investigated that code smells have
negative impact on fault-proneness of a system. Some other studies also
provide evidence about the positive relationship between code smells and
fault-proneness (Li and Shatnawi, 2007; Olbrich et al., 2010; Saboury et al.,
2017). In this regard, Palomba et al. (Palomba et al., 2018b) conducted a
large scale empirical study and confirmed the findings of the previous studies
stating that classes affected by code smells have higher fault-proneness than
other non-smelly classes. They also found that classes affected by multiple
smells are more critical than classes affected by single one (Palomba et al.,
2018a). Our work confirms their findings about the negative impact of code
smells on fault-proneness, where we also show that frequency of different
types of code smell have different impact while considering individual smell
types.

Abbes et al. (Abbes et al., 2011) investigated the impact of two code smells -
Blob and Spaghetti Code on program comprehension. The results showed that a
combination of multiple smells affecting the same source code component
strongly reduces the program comprehensibility whereas the occurrence of a
single smell does not have any impact. Yamashita et al. (Yamashita and Moonen,
2013) also found that developers face more difficulties while working on
classes affected by multiple code smells. In another study, Rahman et al.
(Rahman et al., 2018) showed that feature envy code smells have impact on
naming conventions which reflect the program comprehension.

However, there is a lack of knowledge about the relationship of frequency of
individual code smell type with software fault-proneness. That is, frequency
of which smell types has an impact on occurring more faults, which developers
should focus on while performing refactoring activities. Therefore, it is
necessary to identify whether there exists any relationship between the
frequency of each code smell type and fault-proneness.

##  3\. Empirical Study Design

The study aims to assess the relationship between each of the 13 code smell
types and fault-proneness by analysing their frequencies in 11 well-known open
source software systems, with the purpose of identifying the impactful smell
types.

###  3.1. Formulating the Research Goal

To investigate the relationship, the study particularly aims to answer the
following research question:

RQ: How is frequency of each code smell type related with fault-proneness?

This research question investigates that frequency of which code smell types
has relationship with fault-proneness by analysing their frequency of
occurrences in the software systems. Code smell types those have higher
correlation with fault-proneness are considered as highly ‘impactful smells’
in this study. Therefore, a correlation based analysis is performed to
identify the relationship between them and to show whether smell frequency has
relationship with the fault-proneness. In addition, based on the relationship,
the code smell types are categorized into three impact levels (High, Moderate
and Low) so that developers can focus on the impactful smell types to minimize
the fault-proneness.

###  3.2. Systems under Study

To conduct the empirical study and answer the research question, we have
analysed 11 well-known open source Java systems belonging to two major
ecosystems: Apache111https://www.apache.org and
Eclipse222https://www.eclipse.org/org/. Table 1 summarizes the analysed
systems, latest version, and their size in terms of number of classes (NOCs),
number of methods (NOMs), and lines of codes (LOCs). These systems have been
selected because - (i) The systems of these ecosystems are well-known in the
code smell research domain (Palomba et al., 2018b; Pecorelli et al., 2020);
(ii) these systems exploit Bugzilla333http://www.bugzilla.org. or
Jira444https://www.atlassian.com/software/jira. as issue tracker for
identifying fault related information; (ii) these are in different sizes
(ranges from 75,724 to 1,483,583 LOCs), larger enough having an average NOCs
of 4,685; NOMs of 41,488 and LOCs of 489,093.

Table 1. Software systems involved in the study System | Version | #Classes | #Methods | LOCs
---|---|---|---|---
Activemq | 5.17.0 | 4,747 | 42,349 | 421,979
Ant | 1.9.0 | 1,595 | 13,768 | 138,391
Cassandra | 4.0.0 | 8,101 | 76,237 | 1,483,583
Cayenne | 4.1 | 6,656 | 41,339 | 485,781
CXF | 3.5.3 | 11,109 | 103,490 | 1,120,148
Drill | 1.10.0 | 6,414 | 60,203 | 533,478
Jackrabbit | 2.9.0 | 3,209 | 29,053 | 332,826
Jena | 4.5.0 | 7,077 | 66,138 | 576,575
Pig | 0.9.2 | 2,222 | 15,433 | 231,371
Poi | 5.2.2 | 4,291 | 40,032 | 413,657
Xerces | 2.9.1 | 800 | 9,809 | 131,326
Total | 56,221 | 497,851 | 5,869,115
Average | 4,685 | 41,488 | 489,093

###  3.3. Detection of Code Smells

To carry out the empirical study, a list of 13 code smell types has been
selected as given in Table 2 (first column). For the detection of these smells
from the selected systems, a state-of-the-art tool named DECOR (Moha et al.,
2009) has been used because the tool detects a large number of code smell
types (18 smell types), shows good accuracy and has widely been used in the
previous studies (Pecorelli et al., 2019; Palomba et al., 2018b; Khomh et al.,
2012). We have chosen these code smell types for the study because - (i) the
smells are representative of design and implementation problems, (ii) the
frequencies of these smell types are great in numbers to conduct the study,
and (iii) their frequencies of occurrences are almost similar between open
source and industrial systems (Rahman et al., 2022). Moreover, we have
excluded 5 code smell types out of 18 detected by DECOR as these smells do not
occur in almost all of the systems (Rahman et al., 2022).

###  3.4. Detection of Fault-proneness

The fault-proneness of a class is measured as the number of bug-fixing changes
in a class from its previous to current analysed version, as after fixing a
fault, it can be detected from the source code. These changes include both
addition and deletion statements in source code through commits which are
referred as bug-fixing commits. Bug-fixing commits are identified by searching
commits that contain Issue ID or Bug ID in commit messages. The search is
performed using regular expression. For example, the following commit message
from Cayenne project 555https://github.com/apache/cayenne can be identified
with the regular expression “CAY-\\\d+”:

> “CAY-2732 Exception when creating ObjEntity from a DbEntity”

Using Issue ID found in commit messages, the corresponding issue report is
extracted from the issue tracker such as Jira and Bugzilla. Issues related to
bugs are separated, i.e., the type of issue is bug, excluding enhancement type
issues. To exclude duplicated or false-positive bugs that can bias the result,
only bugs that have the status Closed or Resolved and the resolution Fixed are
considered (Palomba et al., 2018b). Finally, the number of bug-fixing changes
of a class is calculated as the sum of added and deleted lines only through
bug-fixing commits.

Furthermore, we split fault-proneness based on the classes of each individual
type of the 13 code smells to have smell level fault-proneness. For example,
fault-proneness of classes having Anti Singleton smell type are separated to
have of that smelly fault-proneness. In this way, we have 13 types of fault-
proneness for the 13 code smell types. The source code of fault-proneness
detection and dataset including metric scores used in the study have been
given here666https://tinyurl.com/mr39cw93 for replication and further research
purposes.

###  3.5. Definition of Several Metrics

Our study is based on the frequency of code smell types and fault-proneness in
the systems. Therefore, before analysing the relationship, we define the
following several metrics for the study.

  1. (1)

Smell Frequency, SF: frequency of occurrences of a code smell type in a
system.

  2. (2)

Total Smell Frequency, TSF: frequency of occurrences of a code smell type in
all the analysed systems.

  3. (3)

Average Smell Frequency, ASF: frequency of occurrences of a code smell type
per system (TSF divided by the number of systems).

  4. (4)

Fault-proneness, FP: number of faults of a class in a system. Specifically, we
calculate FP for a code smell type as the number of faults of a class having
the code smell type in the system.

  5. (5)

Total Fault-proneness, TFP: number of faults of classes in all the analysed
systems. Specifically, we calculate TFP for a code smell type as the number of
faults of classes having the code smell type in all the systems.

  6. (6)

Average Fault-proneness, AFP: number of faults of classes having a code smell
type per system (TFP divided by the number of systems).

###  3.6. Data Analysis

In this sub-section, we explain how we analyze the data to answer the research
question. More specifically we discuss how we calculate and analyze the
metrics and categorize these (particularly ASF and AFP), calculate Spearman
rank correlation coefficient and interpret it, and finally validate our
findings by experts.

At first, we have analysed the frequency of each type of code smells and
fault-proneness of the corresponding smelly classes in the analysed systems.
Then we have Smell Frequency (SF) and Fault-proneness (FP) for each of the
systems. By summing up the SF and FP for all the systems, we have calculated
Total Smell Frequency (TSF) and Total Fault-proneness (TFP) respectively for
each smell type. After that, we have measured Average Smell Frequency (ASF)
and Average Fault-proneness (AFP) per system respectively. Moreover, we have
categorized the metric ASF and AFP values into three levels - High, Moderate
and Low based on the statistical quartiles (Gupta and Kapoor, 2020) \-
quartile 1 (Q1), quartile 2 (Q2) and quartile 3 (Q3), where it is High if the
metric $>=$ Q3; Low if the metric $<=$ Q1; Moderate if Q3 $>$ the metric $>$
Q1. We have made this categorization because it actually provides insight to
understand the frequency level of the corresponding metrics.

Furthermore, to conduct the data analysis, we have used the Spearman’s Rank
Correlation Coefficient (Gupta and Kapoor, 2020) between the smell frequencies
(SF) and fault-proneness (FP) of the corresponding smelly classes of all the
systems. For instance, we have taken the frequency of Anti Singleton smell
type of each system as the x variable and fault-proneness of the Anti
Singleton smelly classes of the corresponding systems as the y variable to
measure the correlation coefficient between them. We have used the Spearman’s
correlation in this study as the dataset does not follow normal distribution.
Specifically, we have followed the guidelines provided by Cohen (Cohen, 2013)
for interpreting the correlation coefficient. It is considered that there is
no correlation when 0 $=<$ r $<$ 0.1, small correlation when 0.1 $=<$ r $<$
0.3, medium correlation when 0.3 $=<$ r $<$ 0.5, and strong correlation when
0.5 $=<$ r $=<$ 1. Furthermore, based on the correlation analysis, we have
categorized the 13 code smell types into three impact levels - High, Moderate
and Low. Here, we have considered strong correlation as High, medium as
moderate and rest as Low impact level of the code smell types.

To validate the findings of the correlation based analysis, we have taken
opinions from two experienced developers (we call them as experts) from two
different software companies. They have 41 (Expert-1) and 19 (Expert-2) years
of experiences in software development and maintenance particularly in Java
programming language respectively. We have asked them to provide the impact
levels (High, Moderate and Low) on the 13 code smell types based on their
experiences on maintenance activities such as – solving faults, changing codes
or features, adding new features to existing software, comprehending programs,
etc. According to their opinions, the results of the impact levels of the
smell types have been compared with our correlation based impact levels. The
findings of the data analysis are shown in the next section.

##  4\. Result Analysis

The result of our study that the relationship between each code smell type and
its fault-proneness is discussed in this section. Based on the relationship,
impact of each smell frequency on fault-proneness is analysed.

Frequency of the code smell types and fault-proneness of the respective smelly
classes.

Table 2 (column 2 to 5) shows the values of smell and fault-proneness related
metrics such as Total Smell Frequency (TSF), Total Fault-proneness (TFP),
Average Smell Frequency (ASF) and Average Fault-proneness (AFP) respectively.
Also, Figure 1 and 2 show the ASF and AFP for each code smell type
respectively to visualize their frequencies.

Table 2. Relationship between Code smell and fault-proneness Code Smell |  | Total Smell
---
Frequency,
TSF
| Total Fault-
---
proneness,
TFP
| Average Smell
---
Frequency,
ASF
| Average Fault-
---
proneness,
AFP
| Correlation,
---
r
p-value
Anti Singleton (AS) | 1372 | 4147 | 114 | 346 | 0.80 | 0.001
| Base Class Should
---
Be Abstract (BCSBA)
99 | 618 | 8 | 52 | 0.00 | 0.988
Blob | 249 | 1276 | 21 | 106 | 0.67 | 0.009
| Class Data Should
---
Be Private (CDSBP)
1272 | 3320 | 106 | 277 | 0.59 | 0.028
Complex Class (CC) | 6307 | 35540 | 526 | 2962 | 0.33 | 0.254
Large Class (LC) | 2610 | 19156 | 218 | 1596 | 0.03 | 0.914
Lazy Class (LzC) | 863 | 337 | 72 | 28 | 0.53 | 0.053
Long Method (LM) | 8526 | 33168 | 711 | 2764 | 0.32 | 0.264
Long Parameter List (LPL) | 2322 | 10051 | 194 | 838 | 0.58 | 0.030
| Many Field Attributes
---
But Not Complex (MFABNC)
22 | 36 | 2 | 3 | 0 (NA) | NA
Refused Parent Bequest (RPB) | 76 | 14 | 6 | 1 | 0 (NA) | NA
Spaghetti Code (SC) | 120 | 308 | 10 | 26 | 0 (NA) | NA
Speculative Generality (SG) | 47 | 364 | 4 | 30 | 0 (NA) | NA
Figure 1. Average frequency of each code smell Figure 2. Average fault-
proneness of each code smell

From these figures and quartile analysis as discussed in the Sub-section 3.6,
we have observed that Long Method, Complex Class, Large Class and Long
Parameter List code smell types have high frequency of occurrences, and at the
same time these respective smelly classes have higher fault-proneness. On the
other hand, smell types with low frequency like MFABNC, RPB and SC have lower
number of faults. Also, smell types with moderate frequency like AS, Blob and
CDSBP have moderate number of faults. Finally, BCSBA, LzC and SG smells have
different smell frequencies and fault-proneness.

Correlation coefficient.

From the above findings, it has been seen that each type of the code smells
has different relationship with fault-proneness, and several high fault-
proneness of smelly classes reflect the high frequency of those smell types
and several are not. This leads to the correlation analysis to identify
whether frequency of the smell types really impacts the fault-proneness and
how the relationship is between them.

Table 2 shows the result of the correlation analysis between frequency of each
code smell type and fault-proneness and its corresponding p-value in the last
two columns. It is noted that, we have excluded four code smell types (MFABNT,
RPB, SC and SG) from the analysis because most of the systems do not contain
any faults for those smelly classes indicating no relationship exists.
Therefore, the table shows 0 (Not Applicable, NA) values for those smells.
Therefore, we consider these four smell types as low impactful smells, and
hence developers might focus on these with lower priority.

However, from the table, we have found an interesting observation that Anti
Singleton, Blob, Class Data Should Be Private and Long Method have strong
correlation, that is, high relationship with the fault-proneness while their
average smell frequencies (ASFs) are not so high except for Long Method. It is
possible that, faults occur more in method levels and developers write a lot
of long methods in the systems, and therefore both of its fault-proneness and
frequency are very high. On the other hand, medium (moderate) correlated smell
types - Complex Class, Large Class and Long Parameter List have higher
frequency. In addition, Base Class Should Be Abstract have both small
correlation and low frequency, and Lazy Class smell type has both medium
correlation and frequency, as it is expected that lower frequent smell types
have lower fault-proneness because of their lower number of classes in the
systems. Therefore, for the research question, we focus on the high and
moderate correlated code smell types, where we can see that their frequencies
are almost opposite of their relationship strength. It has also been observed
that the correlation coefficient is significant for the four code smells where
p-value ¡ 0.05 and one smell where p-value ¡ 0.1.

From the frequency graphs in Figure 1 and 2, we have also observed that high
frequent smell types have higher fault-proneness whereas their correlations do
not follow it. To make it clear, the correlations show how the fault-proneness
of a smell type will increase when the smell frequency increases. On the other
hand, frequency just tells their frequency of occurrences in the systems.

Furthermore, based on the correlation analysis, the three impact levels of the
13 code smell types - High, Moderate and Low have been shown in Table 3
(column - Correlation based). This impact levels, in fact, assist developers
to focus on the impactful smells to minimize fault-proneness in future and
enhance maintainability of a system.

Experts’ opinions.

Table 3. Correlation and Expert based impact of code smells on fault-proneness

|  |  | Correlation based
---
(our findings)
Opinion from Expert-1 | Opinion from Expert-2
Impact Level | High |  | Anti Singleton (AS),
---
Blob,
Class Data Should Be Private (CDSBP),
Long Method (LM)
|  Class Data Should Be Private,
---
Long Method,
Large Class,
Blob,
Complex Class
|  Anti Singleton,
---
Long Method,
Blob,
Complex Class,
Long Parameter List,
Large Class
Moderate |  | Complex Class(CC),
---
Large Class (LC),
Lazy Class (LzC),
Long Parameter List (LPL)
| Spaghetti Code,
---
Long Parameter List,
Anti Singleton,
Lazy Class
| Class Data Should Be Private,
---
Lazy Class,
Speculative Generality
Low |  | Base Class Should Be Abstract (BCSBA),
---
Many Field Attributes But Not Complex (MFABNC),
Refused Parent Bequest (RPB),
Spaghetti Code (SC),
Speculative Generality (SG)
|  Many Field Attributes But Not Complex,
---
Refused Parent Bequest,
Speculative Generality,
Base CLass Should Be Abstract
|  Many Field Attributes But Not Complex,
---
Base CLass Should Be Abstract,
Refused Parent Bequest,
Spaghetti Code

[* Bold fonts indicate that the smell type matches the impact level with our
findings]

As discussed in Sub-section 3.6, in order to validate our correlation based
approach, the viewpoints regarding smell impact from the two experts have been
shown in Table 3. According to their opinions, the smell types which match the
impact level with our findings are labeled as bold font in the table. From the
table, we have observed that our approach is mostly effective for the
identification of high and low impactful sets of code smell types. It is also
noticeable that, high and low impactful sets of code smell types are also
almost similar between the two experts. However, moderate set of smell types
differs according to the experts, and hence it is difficult to label code
smell types as moderate impact. Overall 11 out of 13 code smell types have
been identified as correct impact levels which match with any of the experts,
except Complex Class and Large Class. This exceptions could be because their
average smell frequency and fault-proneness are very high, and at the same
time their average fault-proneness is very higher than their average smell
frequency (almost six times).

Comparison with state-of-the-art approach.

Palomba et al. (Palomba et al., 2018b) showed that almost each of the smell
types has limited i.e., low impact on fault-proneness while removing these
smells from systems. Our findings contrast this finding in a sense that
different smell types have different impact levels such as high, moderate and
low on the fault-proneness. Moreover, experts’ opinions also support the
impact variations of different code smell types on software systems.

##  5\. Threats to Validity

The potential threats to construct validity are related to the accuracy of the
tool used to identify code smells in this study. However, to mitigate this
threat we have used the tool (DECOR) that has been used in previous studies
showing good accuracy. The potential threats to external validity have been
identified of this study while generalizing the findings of the study from the
sample. First, we have used Java systems in our study, and there is a
possibility that the results would be different for other object-oriented
languages, like - C#. Second, results cannot be generalized to other types of
code smells. Finally, we cannot extrapolate our results to other open source
and industrial systems. The potential threats to internal validity concern
factors that could influence our observations. We are aware that we cannot
claim a direct cause-effect relationship between the frequency of code smell
types and software fault-proneness. In particular, our observations may be
influenced by the different factors related to development phases (e.g.,
experience of developers, workload, etc.). We have focused that some smell
types are highly associated with the fault-proneness, while some are not.

##  6\. Conclusion

Our results clearly show that code smells have negative impact on software
fault-proneness, and also certain types of smells such Anti Singleton, Blob,
Class Data Should Be Private and Long Method have high impact though their
frequencies are not very high. So frequency of all the smell types does not
have strong relationship with the fault-proneness. However, it is important to
regularly monitor and address the impactful code smells to maintain good
software quality and reduce the likelihood of faults. Moreover, the shortlist
of the high impactful and frequent smell types helps developers to prioritize
the code smells to be refactored while performing maintenance activities. In
addition, our findings not only help practitioners but also researchers to
develop refactoring tools based on the smell impact. As for future research,
we will focus on other maintainability aspects such as change-proneness to
measure the impact of the individual code smell types.

###### Acknowledgements.

We gratefully acknowledge the funding support of Information and Communication
Technology (ICT) Division, Ministry of Posts, Telecommunications and
Information Technology, Bangladesh through Grant/Fellowship Number:
56.00.0000.052.33.005.21-2, 18-01-2022.

## References

  * (1)
  * Abbes et al. (2011) Marwen Abbes, Foutse Khomh, Yann-Gael Gueheneuc, and Giuliano Antoniol. 2011.  An empirical study of the impact of two antipatterns, blob and spaghetti code, on program comprehension. In _Proceedings of the 15th european conference on software maintenance and reengineering_. IEEE, 181–190.
  * Cohen (2013) Jacob Cohen. 2013\.  _Statistical power analysis for the behavioral sciences_.  Routledge.
  * Fowler et al. (1999) Martin Fowler, K Beck, J Brant, W Opdyke, and D Roberts. 1999.  Refactoring: improving the design of existing code, ser.  In _Addison Wesley object technology series._ Addison-Wesley.
  * Gondra (2008) Iker Gondra. 2008\.  Applying machine learning to software fault-proneness prediction.  _Journal of Systems and Software_ 81, 2 (2008), 186–195.
  * Gupta and Kapoor (2020) SC Gupta and VK Kapoor. 2020.  _Fundamentals of mathematical statistics_.  Sultan Chand & Sons.
  * Khomh et al. (2009) Foutse Khomh, Massimiliano Di Penta, and Yann-Gael Gueheneuc. 2009\.  An exploratory study of the impact of code smells on software change-proneness. In _Proceedings of the 16th Working Conference on Reverse Engineering_. IEEE, 75–84.
  * Khomh et al. (2012) Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, and Giuliano Antoniol. 2012\.  An exploratory study of the impact of antipatterns on class change-and fault-proneness.  _Empirical Software Engineering_ 17, 3 (2012), 243–275.
  * Li and Shatnawi (2007) Wei Li and Raed Shatnawi. 2007.  An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution.  _Journal of systems and software_ 80, 7 (2007), 1120–1128.
  * Moha et al. (2009) Naouel Moha, Yann-Gaël Guéhéneuc, Laurence Duchien, and Anne-Francoise Le Meur. 2009.  Decor: A method for the specification and detection of code and design smells.  _IEEE Transactions on Software Engineering_ 36, 1 (2009), 20–36.
  * Olbrich et al. (2010) Steffen M Olbrich, Daniela S Cruzes, and Dag IK Sjøberg. 2010.  Are all code smells harmful? A study of God Classes and Brain Classes in the evolution of three open source systems. In _International conference on software maintenance (ICSM)_. IEEE, 1–10.
  * Palomba et al. (2018a) Fabio Palomba, Gabriele Bavota, Massimiliano Di Penta, Fausto Fasano, Rocco Oliveto, and Andrea De Lucia. 2018a.  A large-scale empirical study on the lifecycle of code smell co-occurrences.  _Information and Software Technology_ 99 (2018), 1–10.
  * Palomba et al. (2018b) Fabio Palomba, Gabriele Bavota, Massimiliano Di Penta, Fausto Fasano, Rocco Oliveto, and Andrea De Lucia. 2018b.  On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation.  _Empirical Software Engineering_ 23, 3 (2018), 1188–1221.
  * Pecorelli et al. (2019) Fabiano Pecorelli, Fabio Palomba, Dario Di Nucci, and Andrea De Lucia. 2019.  Comparing heuristic and machine learning approaches for metric-based code smell detection. In _Proceedings of the 27th International Conference on Program Comprehension (ICPC)_. IEEE, 93–104.
  * Pecorelli et al. (2020) Fabiano Pecorelli, Fabio Palomba, Foutse Khomh, and Andrea De Lucia. 2020.  Developer-driven code smell prioritization. In _Proceedings of the 17th International Conference on Mining Software Repositories (MSR)_. 220–231.
  * Rahman et al. (2018) Md Masudur Rahman, Rashed Rubby Riyadh, Shah Mostafa Khaled, Abdus Satter, and Md Rayhanur Rahman. 2018\.  MMRUC3: A recommendation approach of move method refactoring using coupling, cohesion, and contextual similarity to enhance software design.  _Software: Practice and Experience_ 48, 9 (2018), 1560–1587.
  * Rahman et al. (2022) Md Masudur Rahman, Abdus Satter, Md Mahbubul Alam Joarder, and Kazi Sakib. 2022.  An Empirical Study on the Occurrences of Code Smells in Open Source and Industrial Projects. In _Proceedings of the 16th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement_. 289–294.
  * Saboury et al. (2017) Amir Saboury, Pooya Musavi, Foutse Khomh, and Giulio Antoniol. 2017.  An empirical study of code smells in javascript projects. In _Proceedings of the 24th International conference on software analysis, evolution and reengineering (SANER)_. IEEE, 294–305.
  * Sjøberg et al. (2012) Dag IK Sjøberg, Aiko Yamashita, Bente CD Anda, Audris Mockus, and Tore Dybå. 2012.  Quantifying the effect of code smells on maintenance effort.  _IEEE Transactions on Software Engineering_ 39, 8 (2012), 1144–1156.
  * Yamashita and Moonen (2012) Aiko Yamashita and Leon Moonen. 2012.  Do code smells reflect important maintainability aspects?. In _Proceedings of the 28th International conference on software maintenance (ICSM)_. IEEE, 306–315.
  * Yamashita and Moonen (2013) Aiko Yamashita and Leon Moonen. 2013.  Exploring the impact of inter-smell relations on software maintainability: An empirical study. In _Proceedings of the 35th International Conference on Software Engineering (ICSE)_. IEEE, 682–691.