후방 정렬 간소화에 의해 편집속도는 놀랄 만큼 빨라졌다. 5MB 길이의 파일 선두에서 문자를 입력할 때 메모리 이동 및 문자열 삽입, 그리고 정렬정보 갱신까지 0.06초 정도 걸린다. 이 시간 중 70%에 해당하는 0.04초는 더 이상 생략할 수 없는 memmove에 의해 소모된 시간이므로 최적화가 거의 완성되었다고 할 수 있다. 파일 끝에서는 메모리 이동 및 재정렬 시간이 거의 걸리지 않으므로 0.000127초가 걸렸다. 펜티엄 3-600에서의 결과가 이 정도이므로 좀 더 최신의 CPU와 고속 메모리를 장착한 시스템이라면 100MB 정도까지도 편집이 가능할 것으로 추측된다. 물론 더 느린 시스템에서는 이보다 못한 성능을 보이겠지만 이 정도면 ApiEdit는 대형 파일 편집을 위한 기본적인 자격을 갖추었다고 생각된다.
그러나 후방 정렬 간소화는 가장 최적화된 최상의 방법이 아니며 더 좋은 방법들도 있을 수 있고 얼마든지 더 개선할 여지가 있다. 이 알고리즘은 기존의 정렬정보 중 재사용이 가능한 것들을 최대한 활용하는 것이 핵심인데 그렇지 못한 상황에서는 어쩔 수 없이 전체 정렬을 한다. 전체 정렬을 하는 경우는 최초 파일을 읽어 왔을 때와 포맷팅영역의 크기가 변경되었을 때인데 이 두 경우는 아직 작성된 정렬정보가 없거나 완전 무효화되었기 때문에 후방 정렬 간소화 방법이 통하지 않는다. 재사용할 수 있는 유사 패턴이 전혀 없다. 이런 경우는 더 이상의 잔꾀 쓰기를 포기하고 처음부터 정직하게 재정렬하도록 했다.
포맷팅영역이 바뀔 때의 문제점을 제외하고 이 방법의 가장 큰 문제점은 두 줄 이상이 삽입, 삭제된 경우는 유사 패턴을 찾지 못하고 끝까지 정렬을 한다는 점이다. 이전 정렬 결과의 같은 줄, 앞 줄, 뒷줄만 비교를 하기 때문에 블록 삭제, 붙여넣기 등의 동작에 의해 유사 패턴이 두 줄 이상 아래위로 이동하면 검색에 실패한다. 이런 단점을 보완하려면 앞뒤로 일정 줄 이상(예를 들어 10줄)을 비교해보면 될 것이나 이 방법도 역시 완전할 수는 없다.
이렇게 비교 범위를 넓히려면 정렬을 시작하기 전에 pLine 배열의 백업을 만들어 두어야 하고 여러 줄의 패턴을 비교하기 위해 더 많은 시간을 소모하게 되므로 정렬의 절대적인 시간이 증가하게 될 것이다. 전후 두 줄 이상에 대해서도 유사패턴을 찾으려고 한다면 기술적으로 얼마든지 가능하다. 하지만 빈도가 높지 않는 이런 경우를 위해 더 여분의 코드를 작성하는 것 자체가 부담스러워 두 줄 이상의 삽입, 삭제에 대해서는 정렬정보 재사용을 포기하기로 했다. 두 줄 이상의 삽입, 삭제에 대해서도 유사 패턴을 찾아 낸다면 효과는 확실히 있다. 하지만 솔직히 말해 귀찮아서 더 못하겠다.
ApiEdit의 방법이 나름대로 괜찮다고 평가하는 이유는 직접 입력하거나 삭제할 때는 두 줄 이상이 한꺼번에 입력되지 않기 때문에 99%이상의 편집 동작에 대해 최적화가 먹혀 든다는 점이다. 나머지 1%에 대해서는 어느 정도 최적화를 포기하고 대신 루틴을 좀 더 간단하게 유지하는 것으로 만족하기로 한다. 이런 후한 점수를 주는 걸로 봐서 평가를 내리는 사람과 최적화를 한 사람은 아무래도 동일 인물인 것 같다.