Refactored code to improve performance.
Author: AllStars101-sudo
Pull request: yes

 # What does this PR do?
 Refactors several segments of code in the `scripts`,`src`,`tests`,`utils` and `setup.py` and increases performance by a bit, using compression methods and newer practices.
 
 No new functions or methods/models were added; therefore no documentation changes were required.
 
 ## Before submitting
 * [ ]  This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
 * [x]  Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
   Pull Request section?
 * [ ]  Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
   to it if that's the case.
 * [ ]  Did you make sure to update the documentation with your changes? Here are the
   [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
   [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
 * [ ]  Did you write any new necessary tests?



Comments:
@LysandreJik Sorry for the ping but I'd like to know your thoughts on this PR and whether I did whatever you had asked me to  do in the [previous one](https://github.com/huggingface/transformers/pull/12639). Thanks!

Hi, I'd like to put my two cents in this PR.

At first, although most of the time we want to make the code concise and shortened, we should meanwhile have the code readable and maintainable in order to let the next contributor easily understand the purpose of a code segment. 

Taking a part of your contribution (src/transformers/commands/user.py ) as an example:
```
- lines = []
- lines.append(row_format.format(*headers))
+ lines = [row_format.format(*headers)]
  lines.append(row_format.format(*["-" * w for w in col_widths])) 
```
Here you used a shortened expression to instantiate `lines` list with the first line at the same time, which is good when you just have one element to be appended; however, the `lines` in this place means to interact with users by displaying a block of text, and we expect that the `append` method will be used many times in order to add additional information. As a result, this change might break the consistency of the code block as it mixed instantiation and appending. On the contrary, making them separated (instantiation & appending new values) can increase the readability for the next contributor.

Here is another example (src/transformers/commands/serving.py):
 ```
 nlp = pipeline(
        task=args.task,
 -      model=args.model if args.model else None,
 +      model=args.model or None,
        config=args.config,
        tokenizer=args.tokenizer,
        device=args.device,
    )
```
Though `or` operator can do the thing well, this change may surprise or confuse the next contributor because we usually use `or` when we have to check whether left or right operand is equivalent to `True`, and here the `None` will always be `False`. As a result, a question in my brain may appear that why we should check/test a value which is always equivalent to `False`.

The other thing is that this PR includes too many changes across numerous files (51 files changed), from setup.py to model definitions. This might lead to a difficulty to review by the maintainers. Therefore, I would suggest you choosing a part of files which are related to each other, and make sure the changes keep readable and maintainable. 

Have a good luck!

> Hi, I'd like to put my two cents in this PR.
> 
> At first, although most of the time we want to make the code concise and shortened, we should meanwhile have the code readable and maintainable in order to let the next contributor easily understand the purpose of a code segment.
> 
> Taking a part of your contribution (src/transformers/commands/user.py ) as an example:
> 
> ```
> - lines = []
> - lines.append(row_format.format(*headers))
> + lines = [row_format.format(*headers)]
>   lines.append(row_format.format(*["-" * w for w in col_widths])) 
> ```
> 
> Here you used a shortened expression to instantiate `lines` list with the first line at the same time, which is good when you just have one element to be appended; however, the `lines` in this place means to interact with users by displaying a block of text, and we expect that the `append` method will be used many times in order to add additional information. As a result, this change might break the consistency of the code block as it mixed instantiation and appending. On the contrary, making them separated (instantiation & appending new values) can increase the readability for the next contributor.
> 
> Here is another example (src/transformers/commands/serving.py):
> 
> ```
> nlp = pipeline(
>        task=args.task,
> -      model=args.model if args.model else None,
> +      model=args.model or None,
>        config=args.config,
>        tokenizer=args.tokenizer,
>        device=args.device,
>    )
> ```
> 
> Though `or` operator can do the thing well, this change may surprise or confuse the next contributor because we usually use `or` when we have to check whether left or right operand is equivalent to `True`, and here the `None` will always be `False`. As a result, a question in my brain may appear that why we should check/test a value which is always equivalent to `False`.
> 
> The other thing is that this PR includes too many changes across numerous files (51 files changed), from setup.py to model definitions. This might lead to a difficulty to review by the maintainers. Therefore, I would suggest you choosing a part of files which are related to each other, and make sure the changes keep readable and maintainable.
> 
> Have a good luck!

Thanks for replying! I'll keep these points in mind and make changes accordingly. Is it okay if I write a few comments explaining a few of these hard-to-read codes or should I not make changes to these altogether? 

Writing comments is a good idea when a code segment itself cannot directly express its purpose. However, in my opinion, the original implementations I mentioned above can clearly deliver its purpose and goal to the next contributor without any comment, and this is the best practice of coding I think (even if the performance has a minuscule difference).

Therefore, I would suggest you making sure which code segment really needs to be refactored (i.e. the change will bring a significant performance improvement such as improved time complexity or increase its readability...etc.)  before refactoring. 

> Writing comments is a good idea when a code segment itself cannot directly express its purpose. However, in my opinion, the original implementations I mentioned above can clearly deliver its purpose and goal to the next contributor without any comment, and this is the best practice of coding I think (even if the performance has a minuscule difference).
> 
> Therefore, I would suggest you making sure which code segment really needs to be refactored (i.e. the change will bring a significant performance improvement such as improved time complexity or increase its readability...etc.)  before refactoring. 

Gotcha, thanks.