Performance hit for media over 1 hour

[pietrop]

Describe the bug

There seems to be a noticeable performance hit for media over 1 hour - in this case 2h 42 min video.

To Reproduce

Prep - get a transcript for along file

these are the steps I followed, irrelevant for the bug itself, but helpful to setup problem, you can skip

• I got this video from vimeo
• used pietrop/electron-video-downloader to get the video, (electron wrapper to youtubedl)
• created a video over 2 hours, closer to 3 by concating shorter video with ffmpeg (ffmpeg-remix on an mp4)
• create transcript using autoedit.io using pocketsphinx option for STT
• exported autoEdit2 json once transcript is ready

Steps to reproduce the behavior:

1. get a long media and STT json transcript
2. Go to storybook demo page
3. Click on 'import transcript' select 'autoEdit2'
   This is the json I used
   three-hours-sample.mp4_26_04_2019_15-12-51.json.zip
4. Click on 'play'
5. Scroll down to text
6. Click on a word, and start typing
7. See error - there's a noticeable lag between when you type and when you see it on screen

Expected behaviour

No lag for videos over 1 hour, same responsiveness as for video under 1 hour.

Screenshots

Desktop

• OS: Mac OSX 10.13.6 - High Sierra
• Browser: Chrome Version 73.0.3683.103 (Official Build) (64-bit)
• Version: @bbc/react-transcript-editor@0.5.1

Additional context

Not sure what's the issue 🤷‍♂️

Might be mostly to do with draftjs?

facebookarchive/draft-js#437

facebookarchive/draft-js#117

Since we use persistent data and aggressively avoid re-rendering, the size of the document should generally not be a problem unless there is a bottleneck somewhere.

https://reactrocket.com/post/draft-js-best-practices/

A feature-rich draft.js editor with lots of decorators and custom block components can easily cause performance issues, especially for large documents. Draft.js doesn’t do anything special to prevent unnecessary rendering of these components, you can however optimize by using the shouldComponentUpdate method, which puts you in control of when your components re-render.

[Laurian]

I used https://github.com/joshwnj/react-visibility-sensor in a similar project, see https://github.com/bbc/subtitalizer/blob/67b9053c0dc630eaf9a4d33afc75379371dd6066/src/components/WrapperBlock.js#L44

[pietrop]

Thanks @Laurian , thought you had come across this before on that project.

posting code here as we haven't got around open sourcing the other project just yet.

import VisibilitySensor from 'react-visibility-sensor';
...

 return (
      <div className="WrapperBlock">
        <VisibilitySensor intervalCheck={false} scrollCheck>
          {
            ({ isVisible }) =>
              (
                <div>{isVisible ? (
                  <TimecodeBlock
                    start={start}
                    min={min}
                    max={max}
                    end={end}
                    id={id}
                    retime={(time, tcStart, tcEnd) => this.props.blockProps.retime(time, key, tcStart, tcEnd)}
                    focus={focus => this.props.blockProps.focus(focus)}
                  />
                ) : <span>…</span>}
                </div>
              )
          }
        </VisibilitySensor>
        <EditorBlock {...this.props} />
      </div>
    );

so, in subtitalizer I kept draft.js as it was but rendered the timecode widget (you have your speaker widgets instead) only when it was visible

basically not rendering any extra decoration around a draftjs block unless it is visible

ok, ok great thanks! going to try out

[pietrop]

@Laurian I've added it

return (
      <div className={ style.WrapperBlock }>
        <VisibilitySensor intervalCheck={ false } scrollCheck>
          {
            ({ isVisible }) =>
              (
                <div>
                  { isVisible ? (
                    <div className={ [ style.markers, style.unselectable ].join(' ') }
                      contentEditable={ false }>
                      {this.props.blockProps.showSpeakers ? speakerElement : ''}

                      {this.props.blockProps.showTimecodes ? timecodeElement : ''}
                    </div>
                  ) : <span>…</span> }
                </div>
              )
          }
        </VisibilitySensor>
        <div className={ style.text }>
          <EditorBlock { ...this.props } />
        </div>
      </div>
    );

made a branch performance-issue-on-long-files

performance is the same, and also the VisibilitySensor component does not seem to be working?

I remember there was an issue around, the WrapperBlock component not updating.
Eg if you go in settings, ⚙️ and change timecode offset, to get that showing in WrapperBlock through TimedTextEditor we had to force a re-render for draftJs 🤷‍♂ - perhaps that's related? and it's not setup correctly?

[jkokatnur]

Is there any update on this issue, we are using this module in our application and also facing a noticeable lag between typed text and reflecting it on the screen. This behaviour is mostly for the large size audio files.

[pietrop]

Hi @jkokatnur
We have a PR where we have been doing some optimisation reducing un-necessary re-renders
#160 however it's still pending review.

And see the last comment in the PR about "paginating" draftJs content, as is something that might be worth exploring as separate branch/PR #160 (comment)

Btw, did you notice what's the duration of audio after which you start to get performance issues?

Do Let us know if you have any thoughts or suggestions on how to tackle this.

[pietrop]

Test update

despite this issue Automattic/simplenote-electron#501 (comment) I've tried with text that has 22 763 words corrsponding to 2h42min.txt copy pasting in draftjs.org demo (so without entities) and it seems like it is editable just fine..

However if you try and copy paste the whole of the Moby Dick book - 215 821 words then it struggles.