RE: 그래프 퍼포먼스가 나오지 않는 현상

[Codeblack]

안녕하세요~

subvi당 3개의 그래프로 총 96개의 그래프를 실시간으로 출력하는 프로그램을 만들고 있는데 그래프의 wave가 툭툭 끊기는 현상이 있어서 질문드립니다.

현재 cpu는 i7 10700으로 꽤 고사양의 cpu를 사용하고 있으나 그림에서 보시는 바와같이 하나의 쓰레드에 작업이 몰리는 현상이 있습니다.

이 부분은 wave를 그리는 그래프를 없앴을 경우 반절로 떨어집니다. 결론적으로 그래프(xy그래프를 사용합니다)에 wave를 그리는 작업이 많은 리소스를 먹는 것으로 확인되었고 이러한 작업이 여러개의 cpu 쓰레드에 분배되지않고 하나의 쓰레드에 몰리는 현상이 있습니다. 

제가 알기로는 labview를 구동했을 경우  코어/쓰레드에 이러한 작업 리소스를 자동으로 분배하는 것으로 알고 있는데 한쪽에만 몰려서 wave 퍼포먼스가 나오지 않는 것으로 보입니다. 

현상을 완화하고자 패널업데이트를 70ms로 돌려서 일부 리소스를 다운시키는데는 성공했으나 퍼포먼스에 큰 변경사항은 없는 상황입니다.

프로그램 특성상 더 낮은 스펙의 cpu에도 구동이 원활하게 될 수 있도록 해야하는데 이러한 프로그램 구동 리소스를 cpu의 다른 쓰레드에 수동으로 분배할 수 있는 방법이 업을까요?

[여리君 · Accepted solution]

코드를 확인해 봐야 알겠습니다만...

기본적으로 그래프는 루프 내에서 배열로 데이터를 누적시켜 그립니다.

코드가 동작해 그래프를 그리기 시작하면, 데이터를 누적하고, 그 누적된 데이터는 코드가 동작하는 동안 지속되므로, 전부 컴퓨터 리소스를 차지하게 됩니다.

한가지 더 말씀 드리자면, LabVIEW에서는 Loop를 하나의 쓰레드 개념으로 설명합니다.

설명 할 때 보면 Timed Loop를 예로 드는데, Timed Loop 설정으로 CPU Core 를 설정 해 줄 수 있습니다.

이러한 기능 때문에 LabVIEW 가 OS 를 이용해 CPU 점유율을 자동으로 배분하지 않는 것으로 보입니다.

코드를 좀 더 부하가 가지 않는 방향으로 나눠서 만들어 보시길 권합니다.

저 같은 경우는 저장을 하고, 탭을 이용해 그래프를 가리고 있다가, 그래프를 볼때 이벤트를 발생해 파일을 읽고, 그 데이터 뒤에 이어서 나머지 데이터를 그리는 방식을 취했습니다.

이게 그나마 조금 낫습니다.

[Codeblack]

실시간으로 계속 그래프를 그려야하는지라...여리군님이 말하는 방법으로는 진행하기 힘들것 같습니다 ㅠ.ㅠ

결국엔 전체 코드를 리빌딩하는 수준으로 가야될 것 같네요..최대한 while문을 없애는 방향으로...

[여리君]

그래프를 최근 일정 시간만 디스플레이 하게 하는 방법도 있습니다.

전체 그래프는 특정 이벤트 때 저장 파일을 불러와 보여주는 방법을 쓰셔도 됩니다.

전체 데이터를 계속 그래프로 디스플레이 한다는 것은 좀 생각해 봐야합니다.

얼마나 많은 데이터일지는 모르겠습니다만, 표시 방법을 타협을 보셔야 할 겁니다.

[초랑]

일반적으로 스레드를 나누는 것이 while 루프를 기준으로 하기 때문에, 

하나의 while 루프안에서 그래프를 그리게 되면 CPU 코어를 나누는 작업은 이루어지지 않을 겁니다.

그리고 연산은 스레드로 나누어지나, 그래프를 그리는 것은  아마도 그래프를 그리는 로직이 따로 있어서 여러 곳에서 작업을 하더라도

하나의 CPU만 사용할 것입니다.(실험적으로 해본 것입니다.)

큐를 사용한다고 해도 별다른 소득은 없습니다. 그래프를 그리는 것 자체가 리소스를 많이 먹으니까요

(큐를 사용할 때는 큐 얻기 하실 때, 크기를 지정해 주시면 더욱 좋습니다.)

여러가지로 실험으로 강제로 CPU를 지정해도 아무 소용 없습니다.

그래프의 실행 속도를 높이는 것은 그래프의 각종 옵션을 끄는 것이 더욱 좋습니다.  오토스케일, 눈금 등과 같은 것입니다.

'동기화된 업데이트' 옵션은 그래프를 그리는 것 자체가 클 경우에는 아무 소용 없습니다.

비동기화된 업데이트(기본값)는, 연산루프는 데이터를 그래프 인디케이터에 넣고 지나가는 것입니다. 그래프를 그리는 것은 다른 로직(숨겨져있는 LabVIEW 로직, 인터렉티브 커뮤니케이션 로직)이 알아서 합니다. 이 로직이 과부하가 걸리면 이 상황처럼 됩니다.

따라서, 조금이라도 그래프 부하를 줄일려면 '인터렉티브 커뮤니케이션 로직' 의 부하를 줄여야 하므로, 그래프를 제외한 다른 컨트롤 인디케이터의 갯수를 줄이는 것이 도움이 됩니다.

이 내용은 랩뷰 도움말에 나오는 내용과 제가 유추한 내용을 결합한 내용입니다.

[초랑]

동일하게 그래프를 그려도(3개) 탭으로 구분하여, 화면에 업데이트 되는 것이 보이지만 않으면

CPU 점유율은 내려갑니다.

값은 들어갑니다. 그래프 업데이트 하는 로직만 동작 안하는 것입니다.

즉, 실제로 눈에 보이는 그래프에 대해서만 업데이트 하므로 96개의 데이터를 업데이트한다에 집중하시기 보다는,

필요할 때 몇개씩만 보여주는 방식으로 사용하시면 될 것 같습니다.

[여리君]

추론이 아니라 맞는 말씀을 하신 겁니다.

게다가 그래프여서 배열이 계속 증가하기 때문에, 리소스 사용률이 계속 증가하게 된다는 거죠.

문제는 많은 데이터를 그래프로 계속 디스플레이 해야 한다고 하셔서 생기는 겁니다.