
## 기본 컴퓨터 시스템

1. 연산장치(CPU, GPU) : 여러 bit를 입력받아 다른 비트 조합으로 변환.
     1. gpu-병렬적, 많은 계산 동시 처리 가능
     2. 한 사이클에 처리할 수 있는 연산의 개수: Instructions Per Cycle,  
     1초에 처리할 수 있는 사이클의 횟수: 클럭 속도. IPC와 클럭 속도를 향상하기에는 트랜지스터를 더 작게 만들어야했기 때문에 한계가 있었음. 
     그래서 다중 스레딩, 비순차적 명령어 처리, 멀티 코어 아키텍처 같은 다른 방법을 모색하기 시작.
     3. 비순차적 명령어처리: 이전 작업 결과와 상관없는 작업을 순서없이 또는 동시에 실행
     4. 멀티 코어 아키텍처(듀얼 코어 등): 실행 유닛 하나에 CPU를 여러개 두어 전체적인 처리량을 키움
     5. 그러나 CPU에 코어가 많아진다고 무조건 실행시간이 단축되는 건 아님. 한 코어가 실행하는 작업에 걸리는 시간이 최대 한계
2. 메모리 장치(메인보드의 레지스터, RAM, 하드 드라이브): 비트를 저장
     1. 데이터를 읽는 방식이 데이터를 읽고 쓰는 속도에 절대적인 영향을 끼침
     2. 조금씩 자주(임의접근) vs. 한꺼번에 많이(순차 접근)? 한꺼번에 많이가 훨씬 빠르게 작동.
     3. 레이턴시latency: 장치가 데이터를 찾기까지 걸리는 시간. 
     하드드라이브는 물리적으로 헤드를 움직여 데이터를 읽으므로 레이턴시가 긴편 vs. RAM은 모든 데이터를 전자적으로 읽어 짧음
     4. 하드드라이브: 읽쓰 속도 느림, 대용량 데이터 저장 가능
     5. SSD: 읽쓰하드디스크보다 빠름. 용량 작음.
     6. RAM: 읽쓰 빠르나 일반적으로 용량이 64GB로 제한적
     7. L1,L2캐시: 읽쓰 매우 빠름. Cpu로 전달하는 데이터는 항상 이 캐시를 거침. 용량 매우 작음
     8. 읽쓰 속도/용량은 반비례. 그래서 시스템들은 메모리를 단계별로 운용함.
     (하드 드라이브에 전체 데이터 저장 -> 일부를 RAM으로 옮김 -> 그중 매우 작은 부분을 L1/L2 캐시로 옮김) 
     그러면 프로그램에서 요구하는 메모리 접근 속도에 따라 데이터를 다양한 곳에 저장가능. 
     또 어떤 데이터가 어디에/어떻게 저장될건지, 몇번이나 데이터를 옮길건지 최적화하면 좋음.
3. 통신 계층(버스): FSB는 RAM과 L1/L2 캐시를 연결. 처리할 준비가 된 데이터를 옮겨 프로세서가 계산할 수 있도록함. 
계산 완료되면 다시 돌려줌. L1/L2 캐시가 빠른 것도 버스가 빨라서임
     1. 컴퓨터 안의 데이터 통신 속도 > 네트워크를 통한 데이터 전송
          1. 버스의 핵심 속성: 주어진 시간 안에 얼마나 많은 데이터를 전송할 수 있는가? 
          1회에 가능한 데이터 양을 나타내는 버스 폭(width)과 초당 몇번 전송할 수 있는지의 버스 주파수(frequency)
          2. 버스 폭이 좁더라도 주파수가 높으면 임의의 메모리 영역을 자주 읽을 때 도움이 됨 (메인보드의 물리적 구조에 따라 바뀜)

### 내가 적용한 것

- 성능체크. 함수 실행에 소요되는 시간을 체크하는 데코레이터를 만들어서 함수에 붙였다. 
그리고 작업관리자로 확인해보니 윈도우 업데이트 관련한 프로세스가 cpu를 30% 점유하고 있어서 문제해결했다. 
이처럼 백그라운드 작업들이 cpu나 디스크 자원에 영향을 준다. cpu, 디스크, 네트워크에 간섭하는 요소가 없는지 계속 살펴볼 것!!!
- 파이썬으로 db를 계속 연결해둔 채로 neo4j에 삽입하는 쿼리를 실행하니 작업 돌려놓고 퇴근을 했다가 
출근하면 중간에 디비가 끊겨있는 경우가 잦음. -> 아예 파이썬으로 쿼리 csv를 만들고, 그 이후 그 csv의 `row`를 실행하도록 해 디비가 중간에 끊기지 않음

## 리스트와 튜플

1. 리스트와 튜플은 배열에 속한다. 배열은 '정해진 고유의 순서'에 따라 데이터를 나열한 것임. 
=> 이런 자료구조에서는 항목의 순서가 항목 자체만큼 중요
2. 리스트: 동적 배열, 튜플: 정적 배열. 튜플을 저장할 땐 메모리 오버헤드가 작고 연산도 명료하게 수행 가능
3. 정렬되지 않은 배열에서 특정 항목을 찾으려면 모든 항목을 검사하게 되는데, 이때 찾으려는 항목이 배열에 없으면 최악임. 
그렇기때문에 해시테이블을 사용하거나 데이터를 먼저 정렬하고 검색하는 것이 좋음.
4. 리스트의 경우 `resize()`를 하면 원래 길이 n+추가된 양m에다가 +a로 여유분을 더 더함. 
리스트에 값을 한번 추가하면 그뒤로도 추가할 확률이 높다고 생각하기 때문. => 
항목을 겨우 10만개 저장하더라도 append를 사용해 리스트를 만들면 그냥 리스트 내포(`[]`)해서 만들때마다 메모리를 2.7배 더 사용함
5. 튜플은 append가 불가 => 새로운 항목을 추가(튜플+튜플)하는 생황엔 항상 새로운 튜플 하나의 메모리를 새로 할당함
6. append를 사용하지 않더라도 리스트는 상태 정보를 관리하므로 튜플보다 메모리를 더 사용
7. 딕셔너리와 셋: 객체 형태의 자료구조
8. 셋: 유일한 키의 모음

## 제너레이터

+ `yield a` : 이 함수는 a에 있던 값을 반환(방출)하고, 다른 값 요청이 들어오면 이전 값을 유지한 채로 실행을 재개해 새로운 값을 방출한다. 
**리스트의 개수만큼 반복해야할때 리스트를 직접 만들 필요없이 메모리를 아끼면서 반복 실행 가능**

## pandas(행렬과 벡터 계산)

+ numpy 위에 구축한 라이브러리. 균일한 타입의 데이터로 이뤄진 열을 입력받아 불균일한 타입의 표로 저장
+ 엑셀 시트같은 자료구조를 사용
+ row 연산할때 종종 임시 중간 배열을 생성해 램 소모 -> 임시 메모리 사용량을 현재 메모리 사용량의 3~5배 정도로 예상하라
+ 팬더스에서 여러 데이터 행에 함수를 적용할때 루프를 사용하는 **전형적인 파이썬 방식이 보통 가장 느림**
+ iteration해서 한 함수를 df 전체에 적용할 때 가장 나쁜 방법

```python
for row_idx in range(df.shape[0]): 
     row = df.iloc[row_idx]   
// iloc으로 df에서 또 검색해서 row 가져오기
```

+ iloc보단 나은 것: `iterrows()`
+ 가장 나은것: 바로 `df.apply(함수, raw=True)` 이때 `raw=True`를 하면 중간 Series 객체가 만들어지지 않음
+ pandas, numpy에서 concat을 반복 호출하면 행이 하나만 추가된 임시 Series가 계속 생기니까 지양할 것. 
리스트를 만든 다음 그 리스트로 Series나 df를 구성하는것이 훨 나음.

### 효율적인 팬더스 개발을 위한 조언

+ 메서드 체이닝(메서드 뒤에 계속 잇는 것) 적당히 할 것
+ numexpr, bottleneck 사용할 것
+ 데이터에 필터를 먼저 적용하는 게 계산 수행 후 필터를 적용하는 것보다 나음
+ dataframe을 진화시키고 새로운 복사본을 만들때 del 써서 예전의 참조를 삭제하고 메모리에서 해제하기
+ 큰 df는 `to_pickle` 하면 디스크에 영속화 가능
+ `inplace=True` 줄이기. deprecated 예정.

## 기타

+ 코드 구조를 잡을 땐 CPU 속도 vs. 메모리 효율성 중 어느쪽으로 최적화해야할지 반드시 결정해야함.


PYTHON

'PYTHON'에 관한 글들을 모아봤어요.

고성능 파이썬